Re: Streamtokenizer

Top Page

Reply to this message
Author: Andrew Haley
Date:  
To: Bryce McKinlay
CC: Tom Tromey, OneGuy, java
Subject: Re: Streamtokenizer
Andrew Haley wrote:
> Bryce McKinlay wrote:
>> On Sat, May 10, 2008 at 3:36 AM, Tom Tromey <tromey@???> wrote:
>>>>>>>> "OneGuy" == OneGuy <oneguyks@???> 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.
>
> GNU Classpath is a GNU project, and copyright in all GNU projects
> must be assigned to the Free Software Foundation. You can combine
> code from the two projects, but we can't do that.


Sorry, I just re-read that and realized it's not clear who "you" and "we"
refer to.

I meant: anyone can combine code from the two projects into another
project, but the FSF won't accept code for the Classpath project
without copyright assignment.

Andrew.