.Net - Slow and bloated?

We use software written in .Net at work and it seems to be really poor. Mainly in the area of speed.

Everything from dialogs, switching tabs, file menu selections, and what not.

It seems as though the whole thing is a big resource hog too.
As an example, If I minimise the application, play around with note pad, then come back to the application, it takes several seconds to restore its state.

Do you find other .Net applications perform in such a poor fashion?

I *think* the program is written in VB.Net. All I can say is, I've used much snappier applications on a humble Amiga 1200 with memory expansion.

For reference the PC in use is a P4 Celeron 2.8Gz, 512MB Ram jobby.

I'm not a big fan od dot net Jim either, I have VC++8 and I think it's make with dot net too, cos it takes a bloody age to fire up! My old copy of VC6 is much quicker, and I sometimes resort to using that!

Progress huh, brilliant! :/

Dabz

I've had no problem with any .net program. The development environment takes forever to install, and the first run through takes a long time load up - after that it works quickly.

I only use ATI CATALYST control center, which is made in .NET, and its bloody slow. Might be ATIs fault though.

The initial compile every time a dotnet program is run could be contributing to the bloated feel.

On the bright side, it seems a lot less painful than Java. (Not that one can really replace the other, since Java works in way more places than .Net)

Chaotic: The Catalyst Control Center is completely ATI's fault. It is without a doubt the worst video card config software ever. Somehow they still haven't noticed that NVidia kicks their ass in that department, and they don't seem to care.

compile on runtime? how is that much better than an interpreted language?

Yep, it is inevitably slow and bloated, a typical MS product. I uninstalled .net and my PC still hadn't fully recovered from using it. But reinstalling Windows and reinstalling Visual Studio V6.0 certainly solved the bloated feel. Stick with VC6.0 if you can.
.net sucks, stupid name as well.

@Mr. Picklesworth: thats it! Im buying nVidia from now on!

Yeah, it runs slow on older systems.

That'll explain why it takes 2 minutes to load the application.

Is it me or are we actually going backwards in development?

It seems as though we are having to buy more beefier hardware just to cope with a fat O/S (Vista for example) and even fatter development frameworks too. Progress indeed!

I write .net applications and they're lightning fast - I guess it comes down to the structure of the application.

There are several optimisations you can run to speed up runtime executables.

They are definately bloated (seems like a minimum of 12MB for even a basic app), although I don't agree that they are slow.

Compared to using VC 6 or unmanaged code, it'll obviously be slower, but it shouldn't be noticably slower for most office/desktop applications.

I would say it is likely more to do with the programming than the framework itself.

Actual application speed differs from your perception of speed. Making an app seem fast is one thing that separates the wheat from the chaff, so to speak. It should be fairly simple to benchmark some algorithm under .Net and then compare it to Visual C code. There's probably some EULA that says you're not supposed to do that though.

Compiling the first time the program is run is a great feature. It can compile with specific optimizations for the users hardware - how is that going backwards?

Personally, I write .NET stuff in my spare time and it's always very zippy and quick to respond. As always, it comes down to the programmer behind the keyboard.

Does a .net application need to re-compile everytime you restart the PC? Or, is it a one-shot deal?
I gather you still need the hefy 22MB .net framework installed on the PC in any case.

I guess the application at our workplace has no optimisations in place. Its just too cumbersome and frustratingly slow to use.
It really feels like the whole app is in 'interpreted' mode.

Could it be because its written in VB.Net?

I like .net as it offers a lot of possibility (the more if you count in mono)...

> Does a .net application need to re-compile everytime you restart the PC? Or, is it a one-shot deal?

Every time the program starts, although it could still be left in memory and not needing a recompile if the computer is not turned off/on (I'm not 100% sure how that works).

It is also possible to compile the program and send it out that way, but I do not know how much that is done.

> Could it be because its written in VB.Net?
No

> I guess the application at our workplace has no optimisations in place

Do you know if the program is compiled under debug or release? If debug that could be causing a slowdown, it's an easy mistake to make too.

It's likely because of the code itself. The language shouldn't matter much these days. I've found .NET can be slow if you do silly things and don't look for better algorithms.

Another thought - if you are doing any kind of graphics programming using GDI+ then that is a dog. Although it is possible to get acceptable performance out of it with a lot of work, not game acceptable but good enough for light graphics work.

Well, the app does indeed rely on graphics stuff but only for rendering labels with various objects (text/barcodes/bitmaps).

I'm just wondered why everything else stalls so much.
Even opening the HELP dialog window you can see the whole thing being built piece by piece.
I assumed it was because .Net was a really poor platform to develop on.

Last question guys, Does .Net use Windows GDI calls or is it doing its own redraw routines?

I've never had a speed issue with .Net. What version of the .Net framework is it using? VB under older versions was somewhat slower on certain operations, but not to the point where it would be terribly noticable. I believe that the newer versions the speed difference is either non-existent or not discernable. Either case, I doubt it's the language choice.


JIT's will do a JIT on an assembly (a .dll or .exe) upon first reference. This happens everytime you run the application. JIT has advantages over native code generation in that it will analyze the PC to create code that best fits the environment. (i.e. if memory is low, the compiler output will create code that accomodates that), as well as other code optimizations. This is default compile behavior.

The Windows JIT code is cached, but only during the run-time "sandbox". I believe the compact framework (WinCE) ejects out-of-scope code, which creates a more "interpreter" like environment.

The other option is N-Gen'ing the code, which only does the code optimizations and not the environment optimizations. This is similar to the way traditional compilers do it, such as VC++/VB 6 and Blitz3D/Max


I always chuckle at the 22MB framework bashing. Prior to .Net, you had the MFC (microsoft foundation class) and MSVCRT (microsoft visual c runtime). They were shipped with earlier versions of windows because windows was built upon these libraries.

Since future versions of windows will be built on .Net technology, they will ship with the framework for the same reason.

The burden of the 22MB download is only for legacy versions of Windows.


Another problem may be in the way your developers are compiling:

Be aware of your build options. If you are compiling in Debug mode, you are shipping a lot of extra code that gets executed in your final build for purposes of linking to a debugger. You may also need to configure your release build to not create pdb files.

The developers need to make sure that production code is compiled in Release mode.

If it's still slow after that, I'd say it's the quality of the program, not .Net itself. It's very easy to write non-performant .Net code if you're a procedural developer.

It could also be that the bottlenecks are on dependencies. If the application utilizes a database, there might be queries being performed on non-indexed fields, or if the network itself is flakey, that will affect the performace too.

I'd recommend that your developers run the application against a profiler. There is one shipped with .Net itself, but there is also a really good one by JetBrains: http://www.jetbrains.com/profiler/

When it comes to performance bottlenecks, 80% of the time, the problem is in 1-5% of the code. A profiler will narrow in on that troublespot very quickly.

There is the cost of starting up, and then when processing reaches a stub of code that hasnt been jit'd yet, it has to jit it. But once thats all taken care of, its very fast.

There are ways to avoid the startup costs though. The framework includes a tool called NGen, which precompiles the il for the machine its run on. That should help with start times.

.NET apps eat up more memory initially, because you have the overhead of the clr, and it also reserves a large chunk of memory for the app.

Warren hit it on the head. Most slow .net apps are due to poor usage, or abuse even..

My 2d library is written in c# using opengl, and the performance is just great :)

If .Net is bloated and slow, then BM is as well.

ie: naw it is not, but people from C++ thinking they are guru in programming with a GC tend to do idiotical stuff ... as they do in BM in their first tries as well ;-)

GC based programming is like learning programming from scratch when it comes to efficiency and speed and it will take its time until switchers are able to program something usefull and so apps might seem to be slow.

But the fact that C# + Managed DX is just 4-6% slower than C++ + DX clearly shows, that .NET = slow is a very untrue myth. (you can make C++ programs as slow as badly written .NET apps by using deref all over and the like)

It's not that slow, but do need a pre-compile when the first time running.

I'm just sick at the 20MB runtime, and someone have found some workarounds to deal.

Get more RAM. 512MB is barely enough to run Windows, let alone actually use it for anything.

.Net is not generally slow or bloated (at least not more so than other applications), and for Windows application development, it certainly beats the alternatives.

I'm doing some graphics browsing type stuff at the moment and the speed is more then acceptable for me in GDI+. In fact, I'm downright impressed. Way better than it's ever been using the raw Win32 API, MFC, or other software libraries.

> I'm doing some graphics browsing type stuff at the moment and the speed is more then acceptable for me in GDI+.

Maybe I was expecting too much, the work I've done involved lots of pasting images with transparent portions. Two major speed killers were.

1 - Do not paste part of an image. Make lots of smaller images instead. I had some 4000+ by 4000+ size images and was pasting a 100 by 100 section, very slow. After taking the 100 by 100 image and first making a seperate bitmap, and then pasting that new bitmap, performance increased dramatically - the difference between stopping the program since it took to long down to doing the work in a couple seconds.

2 - Convert everything to ARGB format.

Well, it's like any API really. You need to figure out what's fast and what isn't. OpenGL and DirectX and even BlitzMax all have their quirks and ways that they like to do things. Go against that grain and you get slapped. Heh.

> Well, it's like any API really. You need to figure out what's fast and what isn't.

True, and I love DotNet. It has that one little thing wrong with it that drives me nuts. So close to perfection (for me) with that one glaring deficit.

It's slower, with a bigger file size, and harder to develop for...but nerds who make $30,000 a year won't look down on you and say "you don't get it"!

> but nerds who make $30,000 a year won't look down on you and say "you don't get it"!

The Java and C++ nerds will though. And anyone doing dotnet work making 30K a year needs to look for a new job.

A little. That margin is very slim now though.


Sure.


Buh? You've clearly never tried to work with it.

I HATE .NET PROGRAMS:

All in ons solution: slow, ugly, bloated, unstable.

I have to use .Net apps in combination with MS Word at my office. It really drives me nuts each time.

That's a lot of hate for what amounts to a code library.

If the .NET apps you use suck, I can assure you that they would suck no matter what language/library they were written in. Shitty code is shitty code. The programmer is at fault.

.

.NET is what separates humans from animals. ;)

That's not really true. I couldn't code this quickly or efficiently before so that's an improvement, isn't it?

And with GDI+, the Windows applications programmer has far more power at his fingertips than ever before. Contrasting .NET to something like MFC or the earlier APIs is night and day. A complete turn around. .NET is a great stride into the future.

.

I wrote a C++ and OpenGL game using .NET at Uni, after spending an hour trying to get the damn thing to compile in VC6.0 (that was a job in itself) I noticed a speed difference.

Comparable to say running your game in Blitz with debug turned on and debug turned off. I know that .NET is slow, as I've seen it with my own eyes. That's all the evidence I need to not use it again.

.

I'd just leave it BrEgOrS. Until computers stop dead and never get any faster to hide the bloatness of Windows, Microsoft have a monopoly on their hands and if the world is stupid enough to buy exactly the same products and utilities time after time on newer hardware. There's nothing any of us can do about it. In a couple of years time something will replace .NET, will be even slower and then we'll be saying .NET was really fast.

It's just life now I'm afraid.

.

.

> Instead of runtime compiling, why not precompile for all possible platforms?

You want bloat - that would be bloat. It is also hard to compile for a system that is not released yet.

OK, so turn it around ... why do you guys consider size of executable and speed of initial execution to be good benchmarks of progress, rather than increasing programmer productivity (which .NET excels at)? I think it all depends on what you consider to be progress.

Me getting more (and better quality) code written in less time means progress to me. And with a compiler that is loaded onto the end users machine and can be updated over time to be faster and smaller, my code will automatically benefit as it will be recompiled on the users machine with each update of said compiler.

.NET programs are not slow if they are coded correctly. It's an API and programmers will have to spend time learning it to get the most out of it. Just like with any other API to date. Nothing is free.

As for the precompiling, remember that it's only doing that -once-. The first time the app is run. It's not even an issue.

.

I'm not going to get into a long, tiresome point by point argument with you.

I didn't say .NET pograms were as fast as natively coded apps. I said they weren't slow if coded properly. There's a large difference there.

Nobody's mind is going to be changed here today. I'm done.

I just can't believe some of the stuff being said in this thread....^_^

Anyways, as stated before twice, you can precompile .NET programs using NGen.

In general .NET performance:

-Has an advantage thanks to ultra fast memory allocation and good locality of reference( related objects tend to fit in cache, less cache misses/stalls ).

-Is at a disadvantage against the best "native" optimizing compilers because of codegen. They get all the time in the world to chew on code, while the jit has to work on the millisecond level. That said, the quality of code improved from 1.0 to 1.1, and from 1.1 to 2.0 by alot. ( Just think about this. Right now it can compete and/or out perform programs output by native compilers. Its only going to get better. )

-Theres also the hit when calling native libraries. The runtime will marshall( convert ) managed types to non managed, and vice versa. For complex types this can be expensive... for simple blittable types( int, float, etc )-- its cheap.

Also unless the call has been marked with the SuppressUnmanagedCodeSecurity attribute-- the runtime may perform an expensive security check. ( This again falls under people not knowing what they are doing )


Regarding a win32 app vs a win forms app. You have to be crazy to try to compare the two.

Win32 in all its glory! ( Thank god code::blocks has a template eh? )

#include <windows.h>

LRESULT CALLBACK WindowProcedure (HWND, UINT, WPARAM, LPARAM);

char szClassName[ ] = "MyWindow";

int WINAPI WinMain (HINSTANCE hThisInstance,
                     HINSTANCE hPrevInstance,
                     LPSTR lpszArgument,
                     int nFunsterStil)
{
    HWND hwnd;
    MSG messages;
    WNDCLASSEX wincl;

    wincl.hInstance = hThisInstance;
    wincl.lpszClassName = szClassName;
    wincl.lpfnWndProc = WindowProcedure;
    wincl.style = CS_DBLCLKS;
    wincl.cbSize = sizeof (WNDCLASSEX);

    wincl.hIcon = LoadIcon (NULL, IDI_APPLICATION);
    wincl.hIconSm = LoadIcon (NULL, IDI_APPLICATION);
    wincl.hCursor = LoadCursor (NULL, IDC_ARROW);
    wincl.lpszMenuName = NULL;
    wincl.cbClsExtra = 0;
    wincl.cbWndExtra = 0;

    wincl.hbrBackground = (HBRUSH) COLOR_BACKGROUND;

    if (!RegisterClassEx (&wincl))
        return 0;

    hwnd = CreateWindowEx (
           0,
           szClassName,
           "My Window",
           WS_OVERLAPPEDWINDOW,
           CW_USEDEFAULT,
           CW_USEDEFAULT,
           640,
           480,
           HWND_DESKTOP,
           NULL,
           hThisInstance,
           NULL
           );

    ShowWindow (hwnd, nFunsterStil);

    while (GetMessage (&messages, NULL, 0, 0))
    {
        TranslateMessage(&messages);
        DispatchMessage(&messages);
    }

    return messages.wParam;
}

LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)
    {
        case WM_DESTROY:
            PostQuitMessage (0);
            break;
        default:
            return DefWindowProc (hwnd, message, wParam, lParam);
    }

    return 0;
}

System.Windows.Forms and c#( this would be even shorter in boo )

using System;
using System.Drawing;
using System.Windows.Forms;

public sealed class MyWindow : Form
{
	public MyWindow()
	{
		Text = "My Window!";
		Size = new Size( 640, 480 );
	}

	[STAThread]
	static void Main()
	{
		Application.Run( new MyWindow() );
	}
}

The resulting binaries weigh in at 20k for win32, and 4k for the c# version. Both versions start in the same amount of time on my machine, but granted-- you do plop more stuff in to the app and the .net one will take longer to start up than the native. As far as startup time goes... I really don't care. The pro's outweigh the cons by far.

The c# version should also run on linux and mac, or any platform where mono exists, without a recompile :O

Comparing performance for event driven apps doesn't make sense, but supposing we did have any kind of gadgets and logic involved, you'd end up in a situation where once again, the .NET version was much easier to code and maintain, while keeping the same level of performance.

You should read the article about rico mariani and raymond chen, writing a chinese/english dictionary reader( C++ converted to a C# version ).

http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

After 6 iterations of code, the c++ version managed to outperform the c# one( Which was ahead by iteration #2 ).

Excerpt..


If that doesn't open your eyes, then I don't know what will.

We don't have to set you straight... Keep up with the curve or get left behind. Blitz and Pure and such are nice little languages and do what they do well. But you aren't going to get hired for a top paying job programming in them. You will in .NET. And since the almighty buck is the last word in life... That's that.

.

.

BrEgOrS, me and you know the truth, stop trying to convince others. Just do what I do use the tools that are right for you, if other people want to use bloat that's disguised by their high end machines, it's their problem, not ours.
Just concentrate on starting and finishing your app instead, don't worry about performance for now. :)

.

.

.

If you're worried about something measured in kilobytes, you have way too much spare time. The extra size is because it now includes the compiled data as well as the pcode in the file.

.Net apps do have some memory bloat, but they perform well enough in my experience.

If .Net apps were typically excessively slow, you'd see way more than one person complaining about it.

As for your other points, C#, C++, VB are all equal in terms of .Net. The same shortened code can therefore be written in C++. All languages compile to the same byte code. AFAIK VB.Net used to sometimes compile to slower code but I believe that is no longer an issue.

Could .Net outperform traditional precompiled C++ code? Certainly theoretically so. Precompiled code may not necessarily be optimised for your particular architecture, whereas .Net code can compile at runtime to use all the CPU optimisations you have.

You could build your own classes/modules/whatever to replicate the functionality .Net provides, but you're missing the point. .Net has that all built-in, so you're saving time not having to ever do that, plus, I suspect Microsoft knows better how to take advantage of their own API themselves. You also get free garbage collection and some other nice stuff.

Since you seem so opposed to the thought of using someone else's convenient API, you can always write unmanaged code and work in C++ exactly as you used to, without using any .Net features and compiling direct to native code in Visual Studio.Net.

I just created a hello world( in c++ targeting the clr ) in vs 2005.. Does come out 33k under release. That is odd. It looks like its sticking other stuff in there, including native code( mixed mode assembly ). I haven't used managed c++ before soo your on yer own there.

C# however gives me a hello world at 3k. And no its not compressed, or using any special magic. Its just raw il(intermediate language) and metadata.

But then again hello world is not a proper example of any language or tool.




I just did!.. please read that ^link^ I posted.

It took the guy 6 tries to beat the .NET version. And he had to avoid all the library stuff, and write his own custom versions!

So I don't doubt that someone who knows there sh*t about x86 can write the most performant code in the world, but if thats the case... why bother with a high level language at all? Its about effort vs reward.

There are other cases as well. Axiom is a direct port of OGRE(c++), using c#. Check this out... http://realmforgewiki.castlegobs.nl/index.php/Ogre_vs._Axiom_Comparision

That was with 1.1 if I'm not mistaken. The 2.0 framework is better. And its going to keep getting better.

There is no hard and fast rule to say which is gonna be faster all the time-- I'd wager right now that more often than not, .NET will be the slower of the two.

But that doesn't mean its slow at all! I don't hear many blitz users complaining about blitz3d's speed, yet c# in most of my tests has had the better of the deal by far.

Back to the original argument-- .NET is not slow, nor is it bloated.

@enay: I'm not on a high end machine at all. 1.2 duron, 512 mb ram, radeon 9000 w/64mb :)

If the .Net Framework upsets you, I suggest you delete msvcrt.dll and a few others and see how you get by running anything.

You can also delete that extra bloat of DirectX and just program the framebuffer direct while you're at it.

You're making up problems that don't exist. Your sig doesn't say "Sinclair Spectrum 48k" after all. I'm guessing you get upset that every 1KB file takes up at least 4KB on your drive too.

I'd be more upset about every .Net app allocating a minimum of 12MB if I couldn't buy 1G of RAM for $100.

I remember my Commodore 64 could fit Hello World in very little space, but by the same token it wasn't a windowed operating system with multitasking and memory protection.

.

.

.

I stated msvcrt.dll and _others_. Most pre .Net apps need much more than just Visual C Runtime, but they have the advantage that Windows ships with them. I'm sure it adds up to far more than 50MB. I can't give you a list because I'm working on a Mac and frankly I can't be bothered feeding your self admitted anal retentiveness :P

You can't justify saving a few $100 over hours of programmer time. Programmers are expensive and their time delays release. If you think you're getting better value out of me spending a couple weeks extra on API work over $100 for extra RAM, I hope you never get in a position where you manage a business. You're assuming my API code is also better than Microsoft's, with less bugs, working faster, etc.

As for worrying that a .Net executable takes up an additional 30k of space, you've gotta be nuts. You realise that a UPX compressed app only saves disk space, which is stupidly cheap now? You do realise UPX decompresses itself in RAM? And you're worried about .Net needing time to compile something before launching?

Also that additional 30k might be a lot for Hello World, but for larger apps it'll become less significant, in fact probably your .Net app will be smaller because you'll be writing less glue code of your own.

As for the Amiga thing, you've lost the plot. Amigas have never had real memory protection. An MMU was practically useless, for the most part, as nothing ever took advantage of it. Amigas never supported multiple users, and Intuition, while lovely in design lacks a lot of things we take for granted now, like something stupidly simple as standard file requesters. Once you start adding MUI, ASL, Exchange, all your necessary Datatypes, you start catching up on that bloat. Obviously you've never used an Amiga post 3.1, talk about bloat.

My Amiga can go on the Internet, but it has a basic browser (can't do standard stuff like CSS or Javascript), is ridiculously slow, etc. It can do it, but it does much much less than current systems, is inherently insecure etc. You would greatly understand the limitations of the Amiga if you'd ever tried to port anything modern to it. I could go on, but I won't.

In spite of your complaints about bloat, etc. you can still happily run XP or 2k, Office 97, Firefox, etc. on a Duron 1200 with 512MB RAM. The only things that really need the latest gear are games, and the latest MS apps with features you'll never use.

That .pdb file is for debugging. You might wanna check if you actually compiled it for release.

.

.

.

.

@Bregors -- I see a pdb file in your listing, so it looks like you are outputting debug info. But either way, I have no reason to lie or make things up. Here's the c# hello world.. all 3,072 bytes of it( and the source too )

DISCLAIMER!! -- dl this at your own risk. If you run it, and aliens abduct your family, and your house is destroyed in a nuclear war... I'm not responsible.

Sorry, but just seen too much silly paranoia and tales of ".net gone bad" in this thread :)

forgot to zip. too lazy to redo. wysiwyg. .NET 2.0
http://www.deviantmachine.com/link/Hello.exe
http://www.deviantmachine.com/link/Hello.cs

for shits and giggles I'm posting this as well. Did this awhile back after someone posted a BlitzMax version of sieves( Sorry can't remember who ).
http://www.deviantmachine.com/link/sieve.zip

It includes source and binaries for b3d, blitzmax, purebasic, cpp, and c# versions of sieve of eratosthenes. I know I did the c# version, and I think I did either the pb and/or b3d version too. Can't really remember.
There was a freebasic version too that stonemonkey helped me with, but I seem to have lost it. Either way... on my system, c# wins on average. ymmv.


I stand by my point that .NET is neither slow or bloated, but really these kinds of tests shouldn't be the basis on what you use.

For instance, in your test, I'd assume that any decent compiler would do constant folding there. Basically reduce all the math to a single value. I think what you're really seeing here is how aggressive each compiler is at unrolling loops( which is important, but not the full story ).

With the current framework, I think more often than not, .NET code will be slightly slower then stuff put out by a good optimizing native compiler. Nothing worth losing sleep over, and definitely not slow in any sense. Good enough to hang with, and occasionally outperform the unmanaged code.

Personally I'm fine with the slower startup, and few percentage points in performance. Its more than made up for with the extra productivity and "goodies" you get with .NET

Anyways....I'm done with this thread now, 'cuz I feel like I'm turning into a broken record lol. So to each there own, though I *strongly* disagree with alot of you ;)

Yes there were tools like Enforcer, however to use it you needed an MMU, which for most Amiga users meant a costly upgrade to an accelerator, even then you still didn't get full memory protection. Since most Amigas didn't include an MMU, no commercial Amiga software of the time used it. Notably OS4 which is still under development still does not include proper memory protection.

As for bloat, I am talking specifically about OS 3.5 and OS 3.9. At any rate, for an Amiga to act like a more modern PC, you're talking about loads of addons, hacks, etc. Obviously it's in a different league completely to Windows in terms of bloat, but it won't fit on one 880k floppy anymore.

You're absolutely right, which is why we all use BeOS now.

I've also found a way to make your Hello World app really tiny!

HelloWorld.bat

echo Hello World

I suggest you do all your programming in DOS now, because it is clearly the most efficient!

.

.

Hmmm... a bit of a naive, if not short-sighted assessment. Most .Net developers are making anywhere between $30-$70 per hour depending upon their experience and role... And believe it or not, a vast majority of that money is earned on writing software that's conceptually quite a bit less complex than some 3d world builder gizmo.

There's a difference between "not getting it", and "not wanting to understand it". Those that are afraid of change, and complacent in their knowledge usually fall in the latter, and are the ones that are usually looked down upon by the nerds. :)



Interesting point if the real world worked this way, or if .Net's "bloat" was as significant as you're trying to make it out to be. As Craig pointed out, the most successful projects leverage what's available rather than re-inventing the wheel. Granted, there are times when what's available does warrant a "roll your own" implementation, but that's more the exception than the rule. By utilizing API's in the standard .Net library (and the vastness of available API's is astounding), you get all the benefits of using a software vendor's libraries, including updates and optimizations in later releases.

Moreover, the so-called bloat is an insignificant, yet necessary evolution of design on the levels of software, compilers and operating systems. .Net assemblies include management code to assist in garbage collection, type safety, configuration metadata, and debugging. If one can't see the value of this, you're probably not in the audience that .Net is targeting the most: those that have had to design/code/maintain an enterprise level application.


This is a fine argument if the expectation is that we will always be in 32-bit operating systems.

Microsoft's motivation for creating .Net isn't just to kill off Java.

A side effect of abstracting the programs into a CPU/OS/environment agnostic intermediate language allows future operating systems to reduce the burden of backward compatability through emulation for applications leveraging IL.

Over time, you'll probably find that your Win32 applications created today will run slower on future MS operating systems, while .Net applications will run as fast or faster than the day they were created. To top it off, it won't matter what CPU those future operating systems target.

Why will they run slower? The same reason Win16 applications run slower on Win32. It will all have to be done through emulation. Win32 APIs and EXEs will have to be "virtualized" and wrapped in an assembly that sanitizes it to the agnostic nature of the operating system. This wrapping overhead will undoubtedly create slower running applications. Slow enough to be non-functional? I doubt it. Slow enough to be noticable? Probably if it's a game. Probably not if it's a word processor.

As Orca eluded to in an earlier response, today, it's somewhat of the reverse. Portions of .Net are "emulated" on top of Win32. As they (MS) make updates to .Net, these emulated bits get replaced. This is part of the reason .Net gets faster with each release.


Apples to oranges. Have you compared the features of the IDEs? Considering Studio's IDE is about a billion times richer... In light of your other analysis, if MaxEdit was a clone of Studio's IDE, wouldn't it be safe to say that it would have similar performance issues?

Anyway.. looks like you're sort of seeing the reason why so many people are excited about it. Welcome to the collective :)

.

Thats worrying. Is it the case if you even compile a simple button oriented GUI to execute sub exes ?

regards,

> Thats worrying. Is it the case if you even compile a simple button oriented GUI to execute sub exes ?


Yes, the framework must be installed to run any program written with it. The one exception (I think) being c++ programs can be written to not require the framework.

.

@BrEgOrs...
My $.02 is usually worth at least that much.. you're welcome :)


Hmmm... the world I've seen is actually the opposite. Different worlds, I suppose.

I imagine there are some computer users that make ill-informed decisions on their software purchases based on price alone. In my experience, this only happens when accountability for that purchase is low (such as a home computer user, or a high ranking manager making a decision without any responsible thought). Responsibly obtaining components is an entirely different topic. My opinion is.. Functionality, support, price, and ROI is the responsible path.


This is usually a religious battle, but I'd say design approach is more important here than language. In a well designed system, language is an implementation detail. In fact, an enterprise application might have a number of applications using a number of languages.



I think what I mentioned in the previous thread is that the .Net platform mostly targets enterprise solutions. In reality, that's where the money is for them. These environments are where they actually charge for Visual Studio (though I suppose some smaller operations could get away with the Express editions provided it doesn't violate the EULA). And the platforms that these applications usually hit are powerful server hardware or powerful developer workstations.

Only really recently has Microsoft started targetting the casual user. .Net has been out for ... what? 7 years or so? And the express editions just came out last year?

That said, the computers you get on a desktop today are about as powerful as the servers were 7 years ago, so it's only natural that they would market .Net to this group of PCs.

You have to be careful when you see minimum and recommended requirements. This has usually went through the marketing wringer before it settles in front of your eyes.

From MS's site:


Technically, the requirements were correct. They recommend 256MB to get .Net alone to operate at the acceptable level for most applications. The requirements of your machine's total footprint (.Net + monolithic Adobe app + Windows itself + whatever else you needed) brought it well above the minimum.

Marketing. Sucks, doesn't it?

That said, I will agree with you on some terms of bloat. System.dll (the basic core assembly leveraged by pretty much every derived .Net assembly) is pretty large. The bloat is there for a reason though... which leads to your next response...



There is a difference between compiling for byte-code IL and compiling for purposes of emulation.

With byte code compilation, the assembly is storing a lot of information about the application. It's storing "type" information, structures, and so on (coined as "Metadata" by Microsoft). More or less, it's shipping a more compact, slightly cryptic version of your source-code. From this type of information, a compiler can be written to best handle the situations presented in this assembly.

Emulated binaries require a fair amount of guesswork on the part of the compiler that needs to translate. Often times, emulation compilers eject code that focus on stability over efficiency.

You've probably used MAME, right? Ever wonder why it practically takes a super computer to run games that ran on Commodore 64 level hardware back in the day? And why some of those emulations are glitchy and unstable?

The guesswork the emulation layer has to go in is largely the reason why.


I'm sorry. I should have been clearer here. A compiler specific to the CPU needs to be written before it can utilize IL. This is true for any other languages using this distribution model (i.e. Java)

This level of abstraction creates platform independent applications.


A lot of the challenge of this is how Windows treats COM. It's not so much the API itself, but the objects that wrap around it. If an API forces the object to break compatibility, it's fatal to the application consuming that object in the COM world. .Net handles the versioning a lot more elegantly with regard to backward compatibility issues (the "bloat"/metadata stores information about the version of the external component it's consuming).


You said they were both running, and it took 7 seconds for the IDE to refocus. Or was I misunderstanding you?

At this point, IL overhead is not an issue anymore. Everything is running as compiled native code.

The 7 seconds is all the threaded operations re-establishing their state.

For example, the studio IDE has an instance of the compiler running at all times to catch errors as you enter them into the editor.


I agree here. They really shouldn't have called it a DLL as they really aren't the same thing (and, under certain compilation conditions, it's actually a .PE file). It's almost like putting a windows .exe on a Mac and expecting it to run there.


Your only choice here, unfortunately, is C++. C++ is already a platform independent language, so Microsoft's approach to it isn't (for as long as they support Win32) to absorb it into ".Net" borg collective, but rather let it co-exist with .Net applications (or emit the .Net equivalents of Win32 if the developer chooses to do so)

2 points;

1] .NET runs like a charm on any machine I use it, or the programs I write it it, on period. Be it Windows, Linux or the Palmtop from work. If you cant deal with it, just stay the hell away from it and stop whining.

2] The new nVidia Controlpanel is the biggest pile of junk i've ever seen. Do NOT go near it. Seriously, you'll regret the day you where born.

.

.

Adobe Acrobat Reader uses .Net?

Seems to be running fine here on Windows 2000 without it.

.

.

I have 6.0.1.

.

.

> I installed a newly built by yours truly AMD Athlon 64 3200+ Socket AM2 with 2x1Gb of 3

> I updated windows and slapped the .NET framework 2.0 on it because I knew the sis would need it later for what she wanted to do with it. Luckily she's not using the .NET apps right now, because I imagine things would be even slower

I have the visual studio 2005 system loaded on a 1.8 athlon with 512 megs of RAM with no noticable slowdown or extra startup time.

slap the 3.0 framework on it while you are at it. :)

Yes Virginia, there IS a Framework3.0. :)

http://www.microsoft.com/downloads/details.aspx?FamilyId=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=en

@ BrEgOrS

Judging by the system you quote in your post, I really can't see why you should have problems like you describe. The system I run most of my .NET stuff on is listed in my sig. Compare it and tell me if that is such an 'uber system'.

.

> Guestimate: You may have installed .NET from the get-go, and never noticed your system slow-down.

Incorrect - I installed .net with the intention of removing it if it slowed down my machine in any way. Although I did not use any actual method of checking the boot time.

>#1. What OS are you running?

Win2K

>#2. What is your hardware setup? CPU/RAM (Dual channel, Speed Rating?)/IDE/SATA(II), etc.

An old 40GIG IDE drive.

>#3. What version of the framework are you running?

Whatever comes with the Standard studio 2005 setup. Not the Express and not the professional.

>#4. What major proggies are you running in the background during VStudio usage?

Nothing. But I thought we were speaking of the effect on boot time.

Now at work I have a DELL 3.X something processor, 512 meg of ram, on which I routinely run the express version of video studio, a MYSQL database, toad for mysql (large program written in dotnet 2.0), and my client program I am developing with no noticable problems. This is a winXP service pack 2 machine. To be fair though, when toad loads up it takes longer then the oracle version of toad that I use on a different machine, once toad is running it works fine.

> slap the 3.0 framework on it while you are at it. :)


I would, but we have standardized the system at work on Framework 2.0, and I don't want to change anything yet. We are only just starting to deplay out to the sites. First go live scheduled for Miami in January (it's great to be able to choose a startup site).

.

> BTW, just to let you guys know, my system is no slouch. It's pretty responsive

That is the strange bit - your system should be able to run dotnet with no problems at all.

My boot time does seem to have increased somewhat after dot net install.... gives you time to make a brew.

I know I said was done with this thread but...

I'm on a 1.2ghz Duron, and I've had no probs at all. To the best of my knowledge, .NET shouldn't affect startup, or other programs at all. It simply sits on your machine quietly, and when windows runs a .NET exe or dll, it kicks .NET into action for that specific program. Unless maybe windows starts up a bunch of .NET services, but I don't think so...

Also, don't expect any performance improvements with 3.0. They should have never named it 3.0, maybe 2.5 would have been better. Its simply the 2.0 framework with additional upgrades for vista features.

The frameworks don't replace previous versions anyway... 1.0,1.1,2.0,3.0... They all coexist and run based on the program calling them.

That's absolutely correct. Currently, on the windows platform, IL compilers exist for 32-bit, 64-bit and pocket PC. Even more platforms exist if you count Mono (though Mono doesn't compile the entire .Net framework)

The point I was making here is that once the JIT compiler(s) are written, all applications utilizing IL can leverage it. It's akin to writing a C++ compiler for each new platform (which, as you know, is one of the first languages typically targetted). The difference here is that the binaries aren't coded to a particular system's native code. That happens later, and code specific to and optimized to the target environment is ejected.


In my experience, backward compability breaks very frequently. DirectX sort of takes the way that you describe, and ships all previous versions with the latest version of the library. (that's why the install size gets larger with every release)

Unfortunately, that isn't the case for every component out there.

It's not nearly as painful with .Net, but any COM library that changes versions and establishes itself in the registry with a new GUID will break applications that expect that previous version. It was a classic idea of good idea (for some things), bad execution (for most things)




And they generally do for backward compatibility reasons.

Somehow, I suspect there is a co-incidental thing happening here, and .Net just seems to appear to be the smoking gun.


Good luck with your project. It was nice bantering with you. :)

.

My 0.02 is simply a congrats to all for the lack of flamelike statements and the incredible educational content of this forum thread... I have been soaking it up like a sponge!

BrEg:
Something dawned on me...

Have you tried clearing out your pre-fetch directory?

XP has a feature(?) that will offset later loading times of frequently used applications to the boot-up process.

Basically, it's caching frequently used programs so that starting up some programs appears instantaneous.

The problem with this is that XP doesn't make an accurate assumption of frequency of use on a fairly green system because no other programs have been used for purposes of comparison. Sometimes it inaccurately labels certain files such as install files as frequently used, and attempts to place them in this cache. I don't believe the pre-fetch cache is managed by the OS, so it will grow over time until it reaches the threshold defined by XP.

After you get everything installed that you want installed, go to this directory, kill everything in it, and re-time your boot-up benchmark... I know in the past that has occasionally improved my boot-up times:

%WindowsRoot%\Prefetch

(i.e. C:\Windows\Prefetch )

.

.

That's interesting. I guess I never measured repeated reboots after removing the pre-fetch.

.

.

.

.

Bregors, when you were talking about creating apps in Win32 instead of .NET, that was right, a lot of people seem to be experiencing slowdown with apps created with .NET.

I think you lost people when you were complaining about the size of executables being bigger by about 10K.
I dont think the overall size of executables will be bigger when creating a real-world application but I could be wrong.

Over all I agree with you,
I have some apps that are written by shareware authors (in C++) they are great, fast startup time, they dont crash,
dont take up much RAM.

The fact that Jim Brown (OP) is experiencing slowdown with a simple GUI app with his system specs is reprehensible BOO MICROSOFT BOO!

<rant>
Ugh.
Why is everyone so afraid of progress and change?

I remember when windows 95 came out. The complaints were practically identical to those in this thread. Why? Mostly because people were attempting to upgrade it on their Windows 3.1 hardware. The brilliant marketing department at Microsoft, in an attempt to reach the largest group of people possible, low-balled specifications. Consequently, this didn't create the most compelling experience for a lot of people. Sound familiar?

As I mentioned earlier, .Net has been out for several years, and only just recently is it being pushed heavily to the home user. Today's home computer hardware is just now at about the levels of the servers that ran the first .Net applications.

.Net addresses a lot of shortcomings of traditional compilers. Including type safety, garbage collection, rapid development, cross platform binaries, and an executable that is compiled in a way that's tailer-made to your current environment. In a lot of ways, it's a design that is tradionally ANTI-Microsoft in nature. Anyone who's been developing software professionally and seriously for a long time will tell you that .Net is one of the things that Microsoft has done right. Even the most rabid Microsoft haters generally admit this.

When you're running a .Net application on under-powered hardware, it's hard to appreciate or even see the benefits.

Truth be told, sometimes powerful software requires powerful hardware. .Net is powerful software. Nobody even questions why 3D Studio Max needs significant processing capability to be usable. .Net is really not that much different.

.Net is an abstract concept, capable of having a life significantly longer than Win32. Hardware doesn't stagnate, and if software didn't try to keep up or anticipate where we will be in the near future, we wouldn't be nearly where we are today. The 32-bit era's death is long overdue, and .Net applications will make the transition to the next evolution in hardware a lot less painful.

Now... how ya like DEM apples? (Speaking of apples... did you know .Net can run on the Mac via the Mono project?)
</rant>

Resistance to change is a fundamental human factor. THere's noting you can do to prevent it. Everyone has it, some people just in a more severe degree than others.

Well it's one of the things Microsoft has done [i]most[i] right. Unfortunately it seems like .Net is moving towards being a less compact API, which is somewhat unfortunate as it's compactness was one of it's greatest features. However the idea that threads should be methods (as opposed to objects, like in Java) is a horrible idea that they need to rectify ASAP. Oh and the long standing windows bug about only being able to update the GUI from the main thread should die a horrible death aswell.

While that's true, a more important aspect is that buying a faster computer is several orders of magnitude more cost effective than optimizing code.

.

we had GUI applications running very smoothly on 200mhz PC's in the past,
theres no need for a 3GHZ PC slowing down while running a simple app. This is not progress

> You have to have the .NET Framework on the target platform before your app will run.

Same thing for JAVA but I don't think many people are calling that excrement. On the fair side to java it is on a couple more platforms then .net

Actually

".NET programs are compiled at runtime"

That' means

".NET exe should be able to build as stand alone EXE".
but MS don't do this, coz no one will want to install .NET1/2 runtime, I think MS has some use with these runtimes like control the client PC or something.

Hey, sometimes you have to break some eggs to get to the omelette.

The GUI applications on that 200mhz machine were also a nightmare to develop.

No. MS doesn't do this as it makes the binaries rediculously large. There are native .Net compilers around if you want to statically link your .Net application so that it can run without the .Net framework (you can get these for JAva aswell).

Doing so is just borderline pointless.

.

I don't know, because I don't use them. A former collegue of mine does, and I can ask him if you want - but I'm guessing Google is probably just as fast.