[Advanced-java] Coding String.indexOf() with ignore quoted
Nikolaos Giannopoulos
nikolaos at solmar.ca
Thu Apr 3 15:10:37 2003
> -----Original Message-----
> From: advanced-java-bounces@lists.xcf.berkeley.edu
> [mailto:advanced-java-bounces@lists.xcf.berkeley.edu]On Behalf Of Carlo
>
>
> Here is Sun J2SE 1.4.1 code for getting a char from a string:
>
> public char charAt(int index) {
> if ((index < 0) || (index >= count)) {
> throw new StringIndexOutOfBoundsException(index);
> }
> return value[index + offset];
> }
>
> The hotspot/JIT compliers will probably perform some optimizations
> similar to the C/C++ complier "inline" feature to remove the actual
> method call from inside your loop. Therefore, there is not much more to
> optimize except removing the index out of bounds check.
Good point. Thanks.
> If you were to get the String's underlying char array (using
> getCharArray()), a new buffer would have to allocated and then the
> contents copied over. This may be more expensive (depending on the
> length of your string) than just doing what you are already doing.
That was why I suggested it as a potential mod to my current approach but
see this additional object creation and copying as a big show stopper.
> Anyway, not sure what your entire program is doing (or if you have already
> done this) but if I were you I would not spend time speculating over the
> performance of this one function but rather look at the entire
> execution of
> your program using a profiling tool. This should give you a better idea of
> were your program needs optimization. OptimizeIt is one such tool I have
> used in the past and it seemed to do the job OK.
<rant>
Why is it that someone can't look at different approaches to an algorithm
without having this comment thrown at them? Sure, CPU's are getting faster
and mediocre code can run quite optimally but that doesn't mean that this is
a *good* thing (MS???).
Moreover, profiling is always the way to go to get your app to run optimally
after the fact BUT there are choices that go into algorithm design/approach
that with very little (initial) effort can go one a long way however if
broadly ignored altogether can lead to a ton of mediocre to crud code.
The other point is that - as in this case - this code is framwork code that
is utilized in diverse apps from fat client client/server apps, to
standalone clients, to server only apps that widely range in functionality
and therefore profiling is not even a consideration at this point. Sure
each app is profiled after the fact but if you know your going to heavily
use a method (in this case for handling CSV data from a server to construct
dynamic gui components) then you may want to give it some additional thought
up front - especially since either way you need to think anyways.
Finally, we have over 100,000 lines of code - it is silly to assume that I
would give this after the fact consideration to every method i.e. if I'm
asking about it it's because I'm looking for opinions for some reason.
This by no means is directed at you Carlo as I honestly *appreciate* your
response its just that I'm rather tired of developers - instead of offering
solutions - resorting to the don't bother - profile it - as a catch-all
blanket solution alternative.
</rant>
--Nikolaos