Latency In Displaying Dialog

[Luc The Perverse]

This is somewhat related to my previous post - but I like to keep separate
questions separate.

What is the best case scenario for latency between a program telling a
dialog to display, and it displaying? Is there a way to streamline or
optimize it? (For instance, I imagine having the dialog already drawn and
then just showing it, as opposed to generating an entire new dialog would be
much quicker.)

I don't understand why it takes so long for a natively compiled (with
Excelsior) application, which is less than 100 kb, and AFAIK, does not
require a separate JVM to be loaded, to display a simple dialog. The
latency is on the order of 2-3 seconds (on my machine, an AMD 1700+ 512 MB
RAM Win XP SP2, 7200 RPM 8 MB Cache HD, GF FX 6600 (or something))

If there is some windows initialization library that can be gotten around
that would be nice. Or god forbid an ApplicationShowDelay (parody of
MenuShowDelay - at least I hope it is a parody)

Rant follows:

It just doesn't make any friggin sense. My seek times on my hard drive are
less than half a second (by 1-2 orders of magnitude?), there is no need for
virtual memory for a 100 kb application, and my processor and GPU run
millions of operations a second. Where is this latency coming from?

Now I do note that I have no such latency if I map CTRL+ALT+C to the
calculator. If this is an imperfection or problem in the compiled
Excelsior JVM or with Java in general then there has got to be a work
around - because once it gets going, Java is fast. Maybe we just got to
get it going before I want to use it.

Note: I am not unreasonable - it doesn't need to load in 1.2 ms. I want to
be able to press my hotkey and begin typing without worrying that the window
is not yet in focus - which will probably not happen in less than 100 ms.
Even if the window is not done rendering, but it remembers and queues my
keystrokes - I can live with that as well. What I am having a problem with
is having to consciously wait before typing.

 

[Chris Uppal]

What is the best case scenario for latency between a program telling a
dialog to display, and it displaying?

No perceptible delay.

But are we talking about the same thing ? From context you aren't talking
about the time taken between a program (which is already running and which has
already created the dialog) asking for the dialog to show, and it actually
appearing. It sounds more as if the delay is split across any or all of:
starting the program
loading and intialising the JVM
loading the necessary classes
loading more necessary classes
// ...etc...
initialising awt
creating the dialog
showing it.

Simple test -- make the program show the same dialog twice separated by some
interval (either the same actual object, or two similar ones). Does the second
exhibit the same delay ?

-- chris

 

[Luc The Perverse]

No perceptible delay.

But are we talking about the same thing ? From context you aren't talking
about the time taken between a program (which is already running and which
has
already created the dialog) asking for the dialog to show, and it actually
appearing. It sounds more as if the delay is split across any or all of:
starting the program
loading and intialising the JVM
loading the necessary classes
loading more necessary classes
// ...etc...
initialising awt
creating the dialog
showing it.

Simple test -- make the program show the same dialog twice separated by
some
interval (either the same actual object, or two similar ones). Does the
second
exhibit the same delay ?

Ok - this is what I assumed, so my idea of having a programming running in
the background - and then telling it to invoke (as opposed to opening a new
instance of the application) would work.

I just need an easy way to trigger my application.

Did you see my hotkey manager thread/question?

 

[Chris Uppal]

Did you see my hotkey manager thread/question?

I did, and even wrote a reply -- but killed it after I re-read your post and
realised that it mostly repeated what you were already saying...

However, it was still there in the drafts list, so I've resuscitated it. Just
ignore the repetition ;-)

-- chris

 

[Luc The Perverse]

I did, and even wrote a reply -- but killed it after I re-read your post
and
realised that it mostly repeated what you were already saying...

However, it was still there in the drafts list, so I've resuscitated it.
Just
ignore the repetition ;-)

I appreciate it

I was about to have to scold the group like that one troll once who got mad
because no one had replied to his pots in an hour or something.

 

[ldv]

I don't understand why it takes so long for a natively compiled (with
Excelsior) application, which is less than 100 kb, and AFAIK, does not
require a separate JVM to be loaded, to display a simple dialog. The
latency is on the order of 2-3 seconds (on my machine, an AMD 1700+ 512 MB
RAM Win XP SP2, 7200 RPM 8 MB Cache HD, GF FX 6600 (or something))

What you observe is caused by hard drives being much slower than CPU
and RAM. Try deploying your app onto a flash disk and see the
difference.

The EXE is 100KB, but it needs to load megabytes of runtime DLLs
containing the Java API classes, plus quite a few DLLs with native
methods. If you compile your app with global optimizations enabled,
those API classes will go into EXE, which will likely be 10-12MB in
size (but will start faster as there will be less executable files to
load.)

Finally, have you used Excelsior JET's executable image optimizer? It
may reduce startup time substantially.

Hope this helps,

LDV

 

[Luc The Perverse]

What you observe is caused by hard drives being much slower than CPU
and RAM. Try deploying your app onto a flash disk and see the
difference.

The EXE is 100KB, but it needs to load megabytes of runtime DLLs
containing the Java API classes, plus quite a few DLLs with native
methods. If you compile your app with global optimizations enabled,
those API classes will go into EXE, which will likely be 10-12MB in
size (but will start faster as there will be less executable files to
load.)

Finally, have you used Excelsior JET's executable image optimizer? It
may reduce startup time substantially.

Hope this helps,

Hmmm

Keeping the program memory resident would definitely fix it

I can live with a 2-3 second start time once

I am making my global hotkey manager project now - trying to figure out the
JNI, and write low level C for windows hook based on a 4 kb MASM example I
have found.