Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers|

Our valued sponsors who help make this site possible
New Relic: Try free w/ production profiling and get a free shirt! 

Site24x7: Java Method-Level Tracing into Transactions @ $12/Month/JVM. Sign Up! 

Javva The Hutt July 25th, 2002

jKool for DevOps
Light up your Apps & get a cool t-shirt

JProfiler
Get rid of your performance problems and memory leaks!


Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:


New Relic
New Relic: Try free w/ production profiling and get a free shirt!

Site24x7
Site24x7: Java Method-Level Tracing into Transactions @ $12/Month/JVM. Sign Up!


jKool for DevOps
Light up your Apps & get a cool t-shirt

JProfiler
Get rid of your performance problems and memory leaks!


Back to newsletter 020 contents | All Javva's articles

Squeezing bytecode

Did you read Norman Richards article, "The smallest Hello World" in the latest JavaDevelopersJournal? What a hoot. Minimizing bytecode size is an aspect of tuning that I rarely need to do. Actually, I've never needed to do it. But then I haven't done any embedded work. I noticed that the techniques Mr. Richards uses are generally applicable if you are in the group of developers that do need to squeeze your bytecodes down to an absolute minimum. I think Jack is extracting the tips over in his latest tips section.

But the whole issue brought up a question for me. This site is called JavaPerformanceTuning.com because it is mostly about improving the performance of your app. What do you call tuning bytecode size? Java Size Tuning? Java Classfile Shrinking Tuning? It sounds awful.

Then I thought of another question. How would you manage to get the fastest Hello World? Well, of course, it depends on what you are measuring. Include the JVM startup time? On which machine, with what resources? I remember Jack's book had a section on startup time, so I had a look. And I realized that the fastest Hello World would involve almost every part of a Java system except for tuning the class itself. Making the "fastest Hello World" is almost exactly the opposite tuning problem to making the "smallest Hello World".

Efficiently getting to sleep

Ever had nights when you just couldn't get to sleep? Too many thoughts racing through your mind. Well go on down/up/across to your computer, fire up and do some work. But first read the following paragraph (from this article "Where's Jini?")

Romano told me his company sees the software world as being in a protocol-intensive period now, citing XML, SOAP, and UDDI as examples; but they see the next cycle as being "protocol-agnostic," offering an opportunity for Jini to move into session and directory spaces now held by the XML-related protocols.

Is it just me, or did your eyes also glaze over before you reached the end of the paragraph. It works every time for me. It's not just the juxtaposition of all those boring acronyms, the paragraph is actually trying to get me excited about the propect of using Jini as a directory service. Zzzzzzzzzzzz.

Diary of a Hutt

June 19. Too clever for my own good. I was only bringing up the idea with Frezian to see what kind of a response it would get. But no, he can't just give me his opinion. Has to drag HasntGotAClue into it. Naturally HasntGotAClue is not going to take it lying down. QA is his domain, and the last thing he's gonna do is sit still while some nobody makes a move. So now they're seriously discussing whether performance testing comes under the remit of development or QA.

June 20. Bigmouth filled me in. HasntGotAClue has apparently been looking for any excuse to grow his department. Stupid me gave him the perfect wedge to start - with me. That's all I need. Well I've learned that HasntGotAClue has got a clue when it comes to office politics.

June 21. Ugh. Could it get any worse? Now Bigmouth tells me that Frezian sees dumping me and Boris as an excuse to expand his development team and improve his stats. Apparently making the applications run faster doesn't show up in his management reports as LOCs or bug fixes, so in management speak we're just a waste of resources.

June 26. I've been fighting a desperate rearguard action. Parsons was dead impressed with the performance improvement of the server, and even brought round a couple of the BIG D's so that I could show the "before" and "after" response times. Parsons was taking all the credit, and I was using that to try to impress on him how effective the current arrangement was. But Bigmouth told me that I had zilch effect. Frezian and HasntGotAClue are in agreement, and Parsons doesn't give, since I stay under him anyway. In a sense I would be better off under HasntGotAClue because he would be able to showcase my work more effectively than Frezian. BUT I'M NOT QA. Not to mention how pleased I was to see Weevil moved to a different department. Even if his cubicle is still about the same distance as it was, at least it's in the other direction.

July 9. Well it's a done deal. As of the end of the quarter, performance becomes a subgroup of QA. I don't actually physically move, though Boris got shunted inwards because Shifty wanted the window seat. It couldn't get any worse than this.

July 17. It just got worse. HasntGotAClue accepted my argument that performance shouldn't be fully integrated into QA, and should remain a separate subgroup reporting to him. I thought I was on a roll. Then he said I'd have an overseer from QA so that we'd be in-phase with QA, he didn't want any communications breakdowns. And apparently the ideal candidate was Weevil, since he was aware of my work from his previous stint in development. Aaaaagggggghhhhhhh!!!!!!!

(Note: all names have been changed to protect the guilty).

BCNU

Javva The Hutt.


Back to newsletter 020 contents


Last Updated: 2017-03-01
Copyright © 2000-2017 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/javvathehutt020.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us