Feedback Requested on Performance Improvement Idea

  • Thread starter Thread starter Joe Keller
  • Start date Start date
J

Joe Keller

Hello,

My CF application utilizes many custom controls that I have not yet taken
the time to place in the Visual Studio.NET toolbox so I must manually code
the creation and assignment of the various properties to the controls (e.g.
Font, Bounds, Parent, etc.).

One thing I've noticed is that if I follow the approach that the Visual
Studio designer utilizes in assigning a Font to a control is that I'm
creating a new Font object for each custom control that I display on the
screen. The code for assigning a Font to an object typically looks like the
following:

lblName.Font = new Font("Tahoma", 8F, FontStyle.Regular);

To minimize the creation of all of these Font objects, I've created an
object with a static Font property that I am using to assign to my various
custom controls. Using this new static Font property, my code looks like
the following:

lblName.Font = MyApp.Font;

Does anyone see any problems with using this approach? It seems logical to
me that this would cut down on the overhead of my application and possibly
speed up the creation of the form (though I have not yet timed it) given
that there are 10-20 custom controls on the screen at any one time.

Thoughts?

Thanks,

Joe
 
Joe Keller said:
Does anyone see any problems with using this approach? It seems
logical to me that this would cut down on the overhead of my
application and possibly speed up the creation of the form (though I
have not yet timed it) given that there are 10-20 custom controls on
the screen at any one time.

Time it and let us know. :)
 
OK - done.

I created two forms each with 20 textbox controls.

Form A used the standard approach of setting the Font property of each
textbox control by creating a new Font object for each Font property.

Form B used the alternate approach of setting the Font property of each
textbox control by using a static Font object.

When creating each form *for the first time* within the application, Form B
was approximately 5-7% faster loading itself than Form A. However, as the
forms were repeatedly created and destroyed within the application (without
exiting the application), the time difference narrowed to the point where
the load times were approximately equal between the two forms (probably due
to caching by the framework).

I haven't been able to determine what impact using a static Font object has
on memory utilization but I would have to imagine that the static Font
object approach would be more efficient than creating a separate Font object
for each Font property.

Joe
 
I'm curious about this as well. It seems that it could save on memory if
nothing else.

There is some great advice in the following two articles:
http://www.opennetcf.org/forums/topic.asp?TOPIC_ID=297
http://msdn.microsoft.com/library/en-us/dnnetcomp/html/netcfimproveformloadperf.asp?frame=true

I have found that simply adding Application.DoEvents() to the form's load
event can take off some time as well. It has some multithreaded tendencies
to it, so think it through.

Thanks,
Chris Craft
http://www.cjcraft.com/
 
Joe,

Thanks for your investigatory work!

Chris,

If you're interested we have a product that will performs the optimizations
outlined in that article automatically. Details at:

http://www.mrgsoft.com

Justin Weinberg
 
Back
Top