Almost all the 3rd party grid controls for .NET are quite good. Most
vendors have rewritten them to take advantage of the new programming model.
Don't use the backward compatible versions if you can help it, and just pick
one and evaluate it.
The performance problems you are seeing are not typical. Are you running
this stuff on a slow computer or one with very limited memory? Does your
program immediately allocate a bunch of big buffers or something that might
choke a machine with too little memory?
The problem with the size of your executable may be the bitmaps. This may
also be causing some of your performance issues. If you set the background
of every label to a bitmap, even though it is the same image, your
executable is going to store the image once for every label. To fix this
problem, don't set the background image with the designer. Add it to your
project as a resource file and load it at runtime for each label. If you
want to get really fancy, write a method that finds all the labels on a form
and automatically sets their background image to something from your
resource file.
The resources are compiled into the executable file. This technique gives
you tremendous control over things, but it isn't automatic.
A program can be precompiled. That is, you can cache the compiled program
generated from the IL once, and use it from then on. The J# installation
does this with all the Java libraries, in fact. I haven't needed to use
this feature before, but it is pretty well documented. For a program with
400K of source, you shouldn't really need to use it either. Your program
should pop up pretty quickly. I suspect there is something else going on
here. It may have something to do with loading 5MB of graphics, or it may
be another performance problem relating to the machines you are targeting.
I've found C# performance to be absolutely stellar. In optimized code, I've
been able to get C# to run 6x faster than Sun's Java on some low level array
manipulation routines (unsafe code, stack based arrays, using pointers).
The startup time varies, but it has never been unacceptable for me. You may
want to try out your app on some more powerful machines and see if the
performance issues change. If they don't, I would recommend that you get
the profiler and start looking into your application, or rig up your code
with performance counters and timing measurement code.
One other thing to look at - there may be some network snafu here. I've
seen performance problems where it took literally one second to open a file
for append. One machine. Not repeatable on other machines. It's worth
checking into anyway. If the application is taking a long time to open but
the CPU usage is sitting at 0, you can safely bet there is something going
on with networking.
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:pDkhb.717645$Ho3.162905@sccrnsc03...
"Martin" <ma******@globalnet.hr> wrote in message
news:bm**********@ls219.htnet.hr... I am using graphics as backgrounds for forms,buttons,labels etc.
The question is: is it faster to load all graphics from files on app
start or
to use it embeded (places in editor during design).
Reason for my question is that application has 5mb, while without
graphics it has cca 400kb.
Graphic files (bmps) take about 200kb (in program, they are repeated
many times, ie almost all labels (around 200) have same background image)).
Have you considered compressing the images? Although I don't remember for
sure, jpeg and png are both supported. You'll probably have to manually
load the graphics rather than using the designer, but it should help reduce
your space usage.
Also, can JIT compiling be turned off and how (I would like the program
to be either compiled on my machine, then not modified, or if not possible,
when it is installed on client machine)? You can use ngen to precompile a given image, it probably won't be quite
as optimized but it can speed up load time.
This .NET has embarassed me several times with it slowness.
It takes a while to open a form when application is started (I have avoided this by using the same form, programmatically created so there is only
one lag), database handling is quite slow (several simple executeScalar
commands take 1-2 seconds), listview is unusable, datagrid is slow if paint is
overriden. On the other hand, graphical possibilites have pushed my
programms ahead of my competitors whenever buyers require presentations
and every time I have sold a program it was mainly due to great looks (not
mine).
If it was not for this graphical advantage, old VB would be better
solution (faster,lighter).
I'm not sure what your doing with database access, but speeds shouldn't be
that bad. Is the database properly designed and indexed and everything? If
it is, ask in the ADO.NET group and see what they have to say, they may be
a ble to point out some problem in your code or some reason for the speed(or
lack there of anyway).
I don't know what kind of trouble your having with ListView, could you
elaborate as to whats wrong. Also posting your questions about graphics to
the winforms and GDI groups will probably get you a better set of
answers(as you are more likely to find experts in the area than here, which is
focused on C# itself).
However, I do know the datagrid is a pain, but it is nicer than waht vb6
gave us. You may want to consider a 3rd party grid, some of them are very
nice indeed. Unfortunatly I'm not having alot of luck remembering any
names...Infragistics may make one.
