I welcome J2SE 6's faster-splash.... re: Java speed-up

[Fernando Cassia <fc...@gmail.com>]

On 2/16/06, Stefano Mazzocchi <st...@apache.org> wrote:
>
>
> which implements a very interesting trick to speed up java startup
> performance: save the hotspot information in a repository (at JVM shut
> down) so that the JIT doesn't have to wait when it starts until it knows
> what is a hotspot to start compiling it. the performance improvements
> are not likely to change the perception that java is awefully slow to
> start up on the desktop, but it's a clever idea.
>
> In the meanwhile, Sun's attempt to solve the same problem in JSE6 is this=
:
>
> http://java.sun.com/developer/JDCTechTips/2005/tt1115.html#1
>
> No comment.

You try to sound clever by making that statement, but imho, despite any
other speed-up work who might be implemented, Sun's solution
is very important, and something that should have been implemented a long,
long time ago. I welcome their implementation, even if late.

Get this: Splash screens sever an important purpose: they're a visual cue to
tell the user that the program is loading (even if it takes a long time).

It's all about PERCEPTION. Java aps are PERCEIVED as slower because
the computer
appears to "freeze" until the program's UI is finally showed on the screen
(after ALL classes -and even more if it uses Swing- needed to run are
loaded- By then, the user is no longer interested in seeing a splash screen,
he's already wondering why it took so long....

See,  most Flash content on the web takes an AWFUL LOT of time to download,
yet if you ask users, they'll tell you that Flash "loads faster" than java.
The difference? Flash applets can show a message RIGHT AWAY and often
display a progress dialog as the rest of the flash cr*p is downloading,
telling the user what is going on. In contrast, java applets (and desktop
applications as well) "freeze" the user experience until the applet (or
desktop app) has loaded.

I wonder why no one has tought about having java auto-load at startup and
having a single instance of the Java VM running all the time, and then pass
control of the first loaded java application to it (as Mozilla or Firefox
pre-loads itself at boot time when the "quick launch" feature is enabled).

FC

Re: I welcome J2SE 6's faster-splash.... re: Java speed-up

[Tim Ellison <t....@gmail.com>]

Anton Avtamonov wrote:
> On 2/16/06, Fernando Cassia <fc...@gmail.com> wrote:
> [snip]
>> You try to sound clever by making that statement, but imho, despite any
>> other speed-up work who might be implemented, Sun's solution
>> is very important, and something that should have been implemented a long,
>> long time ago. I welcome their implementation, even if late.
>>
>> Get this: Splash screens sever an important purpose: they're a visual cue to
>> tell the user that the program is loading (even if it takes a long time).
> 
> Yes, splash screen feature is very important from usability point of you.
> However the problem itself is not completely clear for me: even early
> I was able to show splash screen if I wanted. Obviously, Swing stuff
> takes to much time to be initialized, but it start initialization only
> when the first reference to Swing is processed, i.e. direct or
> indirect call requires UIManager to be loaded. Therefore you can
> easily show splash screen at the begging of the program and continue
> with loading all other 'heavy-weight' stuff then. Does it make sense?
> For instance, I used SWT just to show splash screen quickly and then
> continue with Swing-based UI. Of course, such approach requires VM to
> be completely initialized anyway (in contrast to Mustang's splashes).
> 
> I welcome any approaches which makes JVM start up faster :-)

A common technique is for the launcher to open the dialog box (using
native platform win man of course), then pass the handle to Java to
close after start-up.

Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Re: I welcome J2SE 6's faster-splash.... re: Java speed-up

[Anton Avtamonov <an...@gmail.com>]

On 2/16/06, Fernando Cassia <fc...@gmail.com> wrote:
[snip]
> You try to sound clever by making that statement, but imho, despite any
> other speed-up work who might be implemented, Sun's solution
> is very important, and something that should have been implemented a long,
> long time ago. I welcome their implementation, even if late.
>
> Get this: Splash screens sever an important purpose: they're a visual cue to
> tell the user that the program is loading (even if it takes a long time).

Yes, splash screen feature is very important from usability point of you.
However the problem itself is not completely clear for me: even early
I was able to show splash screen if I wanted. Obviously, Swing stuff
takes to much time to be initialized, but it start initialization only
when the first reference to Swing is processed, i.e. direct or
indirect call requires UIManager to be loaded. Therefore you can
easily show splash screen at the begging of the program and continue
with loading all other 'heavy-weight' stuff then. Does it make sense?
For instance, I used SWT just to show splash screen quickly and then
continue with Swing-based UI. Of course, such approach requires VM to
be completely initialized anyway (in contrast to Mustang's splashes).

I welcome any approaches which makes JVM start up faster :-)


--
Anton Avtamonov,
Intel Middleware Products Division

Re: I welcome J2SE 6's faster-splash.... re: Java speed-up

[Thorbjørn Ravn Andersen <th...@gmail.com>]

Stefano Mazzocchi wrote:

>
> But look at the bright side: there are probably many other really 
> simple yet useful things that can be done to make java more useful on 
> the desktop and this will be a marketing win for alternative JVMs.

That would be to be able to write small java programs which start fast, 
and which does not have a massive JVM overhead for each.

Basically pull the same trick that Microsoft did with their JVM - have 
the preloaded Java environment being able to spin off new instances 
fast, giving the end user the impression that "this is just another 
little program". 

Personally I think it would be great for Linux desktops and utilities.

-- 
  Thorbjørn

Re: I welcome J2SE 6's faster-splash.... re: Java speed-up

[Stefano Mazzocchi <st...@apache.org>]

Fernando Cassia wrote:
> On 2/16/06, Stefano Mazzocchi <st...@apache.org> wrote:
>>
>> which implements a very interesting trick to speed up java startup
>> performance: save the hotspot information in a repository (at JVM shut
>> down) so that the JIT doesn't have to wait when it starts until it knows
>> what is a hotspot to start compiling it. the performance improvements
>> are not likely to change the perception that java is awefully slow to
>> start up on the desktop, but it's a clever idea.
>>
>> In the meanwhile, Sun's attempt to solve the same problem in JSE6 is this=
> :
>> http://java.sun.com/developer/JDCTechTips/2005/tt1115.html#1
>>
>> No comment.
> 
> You try to sound clever by making that statement, but imho, despite any
> other speed-up work who might be implemented, Sun's solution
> is very important, and something that should have been implemented a long,
> long time ago. I welcome their implementation, even if late.
> 
> Get this: Splash screens sever an important purpose: they're a visual cue to
> tell the user that the program is loading (even if it takes a long time).
> 
> It's all about PERCEPTION. Java aps are PERCEIVED as slower because
> the computer
> appears to "freeze" until the program's UI is finally showed on the screen
> (after ALL classes -and even more if it uses Swing- needed to run are
> loaded- By then, the user is no longer interested in seeing a splash screen,
> he's already wondering why it took so long....
> 
> See,  most Flash content on the web takes an AWFUL LOT of time to download,
> yet if you ask users, they'll tell you that Flash "loads faster" than java.
> The difference? Flash applets can show a message RIGHT AWAY and often
> display a progress dialog as the rest of the flash cr*p is downloading,
> telling the user what is going on. In contrast, java applets (and desktop
> applications as well) "freeze" the user experience until the applet (or
> desktop app) has loaded.

My point was that it is *trivial* to patch the C code that implements 
the java JVM loader to add something like that.

On an apple computer, since practically 5 years ago, you can double 
click on a jar file and the icon will start bouncing right away on your 
dock.

My point is: I don't think this is silly, it's a very useful feature, 
but it's *lame* that it took them almost 10 years to realize they needed 
it!

But look at the bright side: there are probably many other really simple 
yet useful things that can be done to make java more useful on the 
desktop and this will be a marketing win for alternative JVMs.

We need to find the tab-browsing-equivalent of a JVM ;-)

-- 
Stefano.

Re: I welcome J2SE 6's faster-splash.... re: Java speed-up

[Dalibor Topic <ro...@kaffe.org>]

Fernando Cassia <fcassia <at> gmail.com> writes:

> I wonder why no one has tought about having java auto-load at startup and
> having a single instance of the Java VM running all the time, and then pass
> control of the first loaded java application to it (as Mozilla or Firefox
> pre-loads itself at boot time when the "quick launch" feature is enabled).

People have thought about it, and done it to death, in so far as it can be done.

It turns out to not work that great in practice for a lot of reasons: the class
libraries are not designed for that, the VMs are not designed for that, the
security model is not designed for that at all, etc. In order to do it somewhat
sensibly, you need isolates, and isolates are having their winter sleep at this
point, judging by the JSR mailing list activity (none in past two months). 

Yay JCP! :)

cheers,
dalibor topic