Having downloaded & (unsucesfully) tried several profilers today, I am resorting to picking someone else brains on this one:
How can I profile my applet, seeing as it WONT run in appletviewer?
I can debug it fine (jswat connect to running VM, sweet!) but I can’t find a profiler that can do the same. or at least I can’t get one to work!
hmm
appletviewer -J-Xprof index.html
It doesn’t run in appletviewer sadly 
what kind of an Applet doesn’t run in AppletViewer? Sounds like you’ve got some problems to sort out before you profile 
There are various reasons. We use a srange page with javascript (to show a pre-loading box, or ‘you don’t have Java’ messages) as well as server access control to the resources. Sufficed to say it works fine in a browser, and the closest AppletViewer comes to running it is this error:
Exception in thread "main" java.util.MissingResourceException: Can't find resour
ce for bundle sun.applet.resources.MsgAppletViewer, key appletpanel.badattribute
.exception
at java.util.ResourceBundle.getObject(ResourceBundle.java:314)
at java.util.ResourceBundle.getString(ResourceBundle.java:274)
at sun.applet.AppletMessageHandler.getMessage(AppletMessageHandler.java:
39)
at sun.applet.AppletPanel.showAppletStatus(AppletPanel.java:701)
at sun.applet.AppletPanel.init(AppletPanel.java:185)
at sun.applet.AppletViewer.<init>(AppletViewer.java:175)
at sun.applet.StdAppletViewerFactory.createAppletViewer(AppletViewer.jav
a:80)
at sun.applet.AppletViewer.parse(AppletViewer.java:1062)
at sun.applet.AppletViewer.parse(AppletViewer.java:996)
at sun.applet.Main.run(Main.java:138)
at sun.applet.Main.main(Main.java:80)
Seeing as the debugger can happily connect to the VM when it is running, I was kind of hoping one of the many profilers out there would be able to do the same. JProbe has some comments on the site about doing this, but when I try with the latest version I just get an full-on access violation from IE.
[quote] Sounds like you’ve got some problems to sort out before you profile
[/quote]
I’ve said much the same before, admittedly because I don’t have the java plugin installed ;D (makes pages load quicker and conserves more memory; also makes mozilla noticeably more stable, sad but true! My OS-crashes from mozilla have gone down by a factor of 5 since I stopped installing the java plugin).
Appletiviewer dies on some situations where it shouldn’t really do so (e.g. if there’s any problem with the certificate it simply quits/throws uncaught exceptions without even an error message), but java version checkers are the only thing I’ve ever seen that wasn’t eventually fixable to work with appletviewer (it usually dies because there’s a recoverable problem it can’t be bothered to recover from; fix all your problems and it runs).
Another example is obfuscators, most of which are broken and shouldn’t be used. Frequently, their bugs kill appletviewer, but a better obfuscator and/or not using one fixes that ;D.
So…until Sun fixes appletviewer’s many bugs there will continue to be plenty of people who cannot run their applets with it. Although I personally think you shouldn’t distribute applets like this, they’re not technically breaking the java spec (appletviewer COULD work if Sun chose to make it adhere to their own specs and actually handle their own exceptions!), and they shouldn’t be left out in the cold. :(.
In the meantime, can’t you just make an extra build with your build system that doesn’t include the java-check stuff that is killing appletviewer? Surely it would be sufficient to profile the applet without that bit?
I was about to say the same thing - just make a special build. For most of my projects it’s not even that difficult to convert it to an application. Incidentily, my latest profile shows that my renderer spends about 60% of the time in the pixel renderer.
I’ve found the same problem with obfuscators. I tried using proguard to reduce the size of my jar, but couldn’t get it to work reliably. I can’t remember the exact errors (something to do with init).
I was hoping to avoid fiddling about to get a version that works with appletviewer
Seeing as the dubugger could connect to a running VM, I was sort of hoping at least one profiling tool out there could do the same. Doesn’t sound like anyone knows of one tho
Finally got it working in appletviewer, and profiled it.
Now I remember why I dislike trying to tune Java
Results:
[quote]1 [root] 0 ( 0%) 2495 (100%)
2 void Thread.run () 0 ( 0%) 2410 ( 96%)
3 void WToolkit.run () 1 ( 0%) 2101 ( 84%)
4 void WToolkit.eventLoop () 2100 ( 84%) 2100 ( 84%)
5 void CSApplet.run () 1 ( 0%) 274 ( 10%)
6 boolean CSApplet.render () 0 ( 0%) 148 ( 5%)
7 boolean DrawImage.copyImage (SunGraphics2D, Image, int, int, int, int, int, int, Color, ImageObserver) 0 ( 0%) 145 ( 5%)
[/quote]
So… 10% spent in my applets run, and 84% in WToolkit.eventloop.
After a fruitless morning googling for what this might be, I have come to the conclusion that either:
a) The profiler is lying.
b) Its telling the truth, and noone knows what this eventloop is doing or how to get it to stop
What is most disturbing is that it runs at exactly the same speed ( 30fps and it should be 50fps) on my 2.4GHz machine, AND on the PII 400MHz low spec machine!! Much wierdness…
Any help in understanding what is goping on would be greatly appreciated 
I’m sure this exact problem has been seen before, and it’s something to do with the way the graphics pipeline is synced and flushed in the windows event loop. Such that it’s never going to be faster than 30Hz.
Cas
I use pretty much the same applett class in my 3D renderer, and that manages 50fps (theres nothing else going on though - no sound etc.). Not sure what else is different, but something Im doing is causing the event loop to fill up.
I’ve had exactly the same problem before, and eventually decided the only “solution” was to stop using AWT, either just for events or for events and rendering. On linux, I would get the same problem but with a completely different method call and library (yet with enough similarity you can guess it’s a similar thing) and usually with much less disappearing into it - although sometimes it would be even worse.
My memory is that ceasing to use events for any input cleared it out (i.e. it was a problem with keyboards and mice rather than rendering - although I was never entirely convinced).
Sorry not to help more, I can only sympathise with your plight (and would dearly like to know more about these impenetrable massive CPU hogs in platform-specific code in the JVM’s…!)
Well Ive made it a better (>40fps)
Only I don’t know how :-/
Maybe the rebuild all fairy granted my wish… ;D
Edit: the AWT mouse is definately a bit squiffy. Wiggle the mouse over the applet and CPU usage goes up by 10%!
This is why we invented LWJGL 
Cas