Re: Streamtokenizer
Andrew Haley <[email protected]>
| Newsgroups | gmane.comp.gcc.java.devel |
|---|---|
| Message-ID | <[email protected]> |
Andrew Haley wrote: > Bryce McKinlay wrote: >> On Sat, May 10, 2008 at 3:36 AM, Tom Tromey <[email protected]> wrote: >>>>>>>> "OneGuy" == OneGuy <[email protected]> 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.