Re: Streamtokenizer
Andrew Haley <[email protected]>
| Newsgroups | gmane.comp.gcc.java.devel |
|---|---|
| Message-ID | <[email protected]> |
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. Andrew.