Graphics and performance issues

  • Thread starter Thread starter Martin
  • Start date Start date
M

Martin

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)).
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)?

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).
 
Martin said:
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)?
Click to expand...

I'm a newbie, but I was browsing through the help and thought this might
help you...

<ms-help://MS.VSCC/MS.MSDNVS/cptools/html/cpconnetframeworkadministrationtoo
lmscorcfgmsc.htm>

Mentions a "Native Image Generator" called "NGEN.EXE". (There's a link to
help with more details on that help page.) I beleive if you generate a
native image, you can use that configuration program discussed on that page
and store the native image in the global assembly cache.

Of course, again, I am a newbie, and I may be wrong.

-Rob
 
Martin said:
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)).
Click to expand...

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)?
Click to expand...
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).
Click to expand...
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.
 
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.
 
The average machine on which my programs run is Compaq P4 2.4ghz.
The main speed problem comes with starting application, even the "Hello
World" form.
Embedded graphics are not main cause of slowness, as when graphics are
removed, speed is almost the same.
I have mentioned problem with listview: when populating it with data from
database (ie 5000rows, 6 columns, it takes a while (after data has been
loaded into dataTable)).
However, when data is reloaded (regardless of disposing datatable, invoking
begin_update,end_update) into listview, it takes 15 seconds to fill (on P4
1.8).
 
Back
Top