Streamtokenizer
Bryce McKinlay
bryce@mckinlay.net.nz
Sat May 10 00:37:00 GMT 2008
On Sat, May 10, 2008 at 3:36 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "OneGuy" == OneGuy <oneguyks@gmail.com> writes:
>> OneGuy> Memory usage was even worse (55 MB with Classpath vs 35 MB with Sun's).
>> It looks like our nextToken will often create a new StringBuffer.
> Perhaps it would be better to make one and cache it.
>> FWIW I'd accept a clean patch to further optimize StreamTokenizer.
> Most likely the only reason it performs poorly is that it never popped
> up as a performance limiter before.
Double.parseDouble() could also be used, avoiding creating a Double each time.
I haven't really been following this stuff, but what is the situation
with merging in stuff from OpenJDK? It looks like they have a better
implementation here which could very easily be dropped in.
Bryce
More information about the Java
mailing list