Clueless about what drives Performance...

[Caleb Tower]

Hey, I'm clueless about performance, but got the contest mailing and thought I'd participate. Beside that I might learn something useful. Actually I already did.
So here's my question what are the key factors driving application performance? Disk reads? User Interface Controls? Computation?
My applications use swing heavily and the screens build slower than our old c++ version (not that I'd go back). One screen (JDialog) in particular builds slowly compared to others. I should look at it but have not yet.
Are there performance blunders in working with Swing? How about building complex Strings?
Any Thoughts?
Caleb T

[David Weitzman]

So here's my question what are the key factors driving application performance? Disk reads? User Interface Controls? Computation?
Yes, yes, and yes. Swing is known to be a bit sluggish at times, but in the end there isn't a simple formula for getting good performance. Disk speed is very often the limiting factor in the speed of certain applications. Some algorithms are better than others. When you use an external library like Swing, a system feature like File access, or make an algorithic choice, it's good to make sure you're aware of the performance implications. Any time you're unsure you can just write a few benchmarks.
Are there performance blunders in working with Swing?
I'm not a Swing expert, but I'm sure there are plenty. You might want to check out the Swing forum for info on that sort of stuff.
How about building complex Strings?
When constructing complex String, it's usually best to use a StringBuffer. Just concatenating plain old Strings with the '+' operator can get pretty slow if done in repetitively or with large Strings.

[Ilja Preuss]

Originally posted by David Weitzman:
How about building complex Strings?
When constructing complex String, it's usually best to use a StringBuffer. Just concatenating plain old Strings with the '+' operator can get pretty slow if done in repetitively or with large Strings.

Well, only if you build the string incrementally. If you build the string in one big expression, a StringBuffer will be used internally, anyway:

myString = s1 + s2 + double1 + .... + "foo"; // no need to use StringBuffer here

Most often you will want to use StringBuffers when constructing Strings in a loop or the like. As with any other performance optimization, I would only do that when a profiler showed me that the construction was a bottleneck.

[Avi Abrami]

More information about "String" concatenations (and its relationship to the "StringBuffer" class) is available in the String Literals section (section 3.10.5) of the Java Language Specification,
http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#101083
and in "Issue068" of the Java Specialists' Newsletter
http://www.javaspecialists.co.za/archive/Issue068.html
Hope this helps.
Good Luck,
Avi.

[Gavin Bong]

Originally posted by Caleb Tower:
My applications use swing heavily and the screens build slower than our old c++ version (not that I'd go back). One screen (JDialog) in particular builds slowly compared to others. I should look at it but have not yet.
Caleb T

Caleb,
Can your app be reengineered to other GUI frameworks ? Eclipse.org's SWT framework is more responsive then SWING. But be sure to read the fine-print & legalese in their license - to ascertain the distribution rights of apps build on SWT.
Gavin

[Wouter Zelle]

Originally posted by Gavin Bong:
Can your app be reengineered to other GUI frameworks? Eclipse.org's SWT framework is more responsive then SWING. But be sure to read the fine-print & legalese in their license - to ascertain the distribution rights of apps build on SWT.

I dunno. It seems to me that he has only one screen that is too slow. I would certainly try to optimize this screen instead of expending a lot of effort to move to SWT with uncertain results.

[Ilja Preuss]

Originally posted by Avi Abrami:
"Issue068" of the Java Specialists' Newsletter
http://www.javaspecialists.co.za/archive/Issue068.html

Interesting article. But the following paragraph struck me as very odd:

It does not actually matter which compiler is better, either is terrible. The answer is to avoid += with Strings wherever possible.

I wonder what he thinks the compilers *should* do - after all, Strings *are* immutable.
And "avoiding += with Strings wherever possible" is just plain stupid - first because it can be avoided *always*, second because his proposed solution seems to be to replace it by using StringBuffers explicitely (that is, in many places you would just do the work of the compiler), and last but not least, the usage of += is intention revealing and a substitute will probably just make it harder to read (which will be more costly than the slight performance hit in most cases).

[Avi Abrami]

Hi Ilja,

And "avoiding += with Strings wherever possible" is just plain stupid

In my (limited) experience (regarding actually tweaking applications in order to improve their performance), I currently feel that there are _so_ many variables that affect performance, that it is _very_ difficult to define axioms -- such as "avoiding += with Strings wherever possible".
So I guess I am agreeing with your sentiments (to a degree :-) ). But in any case, Dr. Kabutz is _extremely_ responsive to eMails he receives, so allow me to suggest that perhaps you take up the issue directly with him.
(And perhaps you can let us know the outcome )
Cheers,
Avi.

[Stepan Samarin]

Originally posted by Avi Abrami:
...I currently feel that there are _so_ many variables that affect performance...

True, but in most cases performance problems lie in an inter-component communication. So, thought-of architecture + design usually solve the problem. Developers can produce ugly code, but if architecture and design are rock-solid, it's ok...profiling and code-covering tools would do the work.

[Ilja Preuss]

Originally posted by Avi Abrami:
But in any case, Dr. Kabutz is _extremely_ responsive to eMails he receives, so allow me to suggest that perhaps you take up the issue directly with him.
(And perhaps you can let us know the outcome )

Sounds like a good thing to do - sadly I am currently so busy with other things of higher priority, that I don't think this will likely be happening in the near future...

[Avi Abrami]

Hi Ilja,

sadly I am currently so busy with other things of higher priority

What, like participating in this forum? :roll:
Avi.

[Ilja Preuss]

Originally posted by Avi Abrami:
What, like participating in this forum? :roll:

Yes, of course! And moderating the UML forum, including driving forward the "How to design OO systems" thread. Don't you think these activities *deserve* high priority?