|
So you like words (four byte values?) as they can be atomically compared instead of the more complex String comparison?Not to travel too far down this road, but multi-byte compares in i5/OS are pretty low-level, and I don't think it's so much of a word thing. Power chips are 64-bit machines, anyway, so my guess is that if you go that far down anything less than eight bytes is a pretty fast compare.
An RPG aversion against calling subroutines? *B*Not sure what you mean by this. I have absolutely no aversion to calling subroutines or procedures. Good RPG, especially /free, is every bit as modular as Java or indeed any other language. In fact, I prefer RPG procedures because I can pass multiple input/output parameters; it's a very nice technique.
Or just the subconsious doing continouos microoptimizations? That is really a mind set hard to get rid of :)I don't ever eant to get rid of continuous micro-optimizations. That's why my code is very, very fast.
I'd like to hear them. Get it all out! Feel better!!Nope. I've done it in the past. The BigDecimal alnoe is enough to kill the entire language in my estimation. Add in a lack of an integrated ISAM database and I get ill thinking about writing real business applications.
So these performance problems is not per se the fault of the JVM but somebody doing stuff in the wrong place, if I understand you correctly. Probably much worse than allocating a few extra String objects :)I think the JVM is a work of art. I think the i implementation of the JVM, especially the seamless integration between Unicode and ECBDIC, is nothing short of genius.
I agree on the varying quality of open source projects. That is where reputation comes in - I tend to expect more from a mature Jakarta project than from a stale sourceforge project with a single developer, but both may be very useful to you in the situation.Just don't put the latter into production. Use it for proof of concept then rewrite it if you need it.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.