P
pdxfilter-google
We have a "heavyweight" Windows Forms app that uses several large
dependent DLLs containing various UI components.
There is a significant delay (~2 sec) when loading a form the first
time. This comes from the CLR compiling the form methods as well as
any 3rd party controls we're using.
On startup, our app displays a login screen. It would work out nicely
if the CLR could get a "head start" on the JIT process while this
screen is displayed. In fact, we've had some luck starting a low
priority background thread that creates some common objects and calls a
few methods. This allows enough "precompiling" to noticeably cut down
the initial display time of the form.
I'm very curious whether there is any better way to force the CLR to
JIT a particular class (or even entire assembly). It's messy to
attempt to call methods in a haphazard way, trying to get "coverage".
NGEN is not workable for us, for a variety of reasons.
Any suggestions from CLR gurus would be appreciated, hack or not.
We're looking to make this app snappy. Thanks!
Jon
dependent DLLs containing various UI components.
There is a significant delay (~2 sec) when loading a form the first
time. This comes from the CLR compiling the form methods as well as
any 3rd party controls we're using.
On startup, our app displays a login screen. It would work out nicely
if the CLR could get a "head start" on the JIT process while this
screen is displayed. In fact, we've had some luck starting a low
priority background thread that creates some common objects and calls a
few methods. This allows enough "precompiling" to noticeably cut down
the initial display time of the form.
I'm very curious whether there is any better way to force the CLR to
JIT a particular class (or even entire assembly). It's messy to
attempt to call methods in a haphazard way, trying to get "coverage".
NGEN is not workable for us, for a variety of reasons.
Any suggestions from CLR gurus would be appreciated, hack or not.
We're looking to make this app snappy. Thanks!
Jon