good point. change that to "other issue" On 3/4/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > > Will Glass-Husain wrote: > > By the way, it'd be nice to see if the pooling is really necessary as > > Jonathan suggests. > > Garbage collection preformance of mainstream JVMs have changed > significantly > > since Velocity was first written. The issue is whether instantiation of > a > > javacc parser is still expensive. > > Those are two different issues, GC and parser instantiation? > > > > > WILL > > > > > > On 3/3/06, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> I'd argue that SimplePool is a utility class and not part of the public > >> API (so it's ok to change this). Have to draw the line somewhere - > >> otherwise we can never change anything. Anyone object? > >> > >> I'm not really following the problem with factories -- I'll wait to see > >> until I see some code to comment on this. > >> > >> Llewellyn Falco has a Eclipse code formatting file. I had a copy but > my > >> computer is in the shop. Llewellyn are you out there? > >> > >> Best, WILL > >> > >> > >>> a) I realize that someone might have used SimplePool in their app, so > >>> renaming the impl and making SimplePool an interface would create an > >>> upgrade problem. so creating new classes. > >>> b) the class is SimplePool and the logic and field is called > >>> parserPool. I decided the new classes should use parser pool in the > >>> names. > >>> c) pools usually operate with a factory concept, which is hard with > >>> how the current code is structured (the pool owner populates and > >>> instantiates extra instances if there's a problem). I have to > >>> simulate the factory concept with a callback interface, or something > >>> like that, which is odd to pass since velocity you usually just > >>> initialize with the runtimeservices. > >>> d) code formatting... I don't suppose anyone has the Eclipse code > >>> formatting rules? I'm trying to follow conventions as much as > >>> possible, but if someone can share that, that would be very helpful. > >>> e) I'll have the commons pool impl available as well, though I doubt > >>> that would get added into the engine branch. Where do you think we > >>> should stick that? > >>> > >>> -- > >>> Serge Knystautas > >>> Lokitech >> software . strategy . design >> http://www.lokitech.com > >>> p. 301.656.5501 > >>> e. [EMAIL PROTECTED] > >>> > >>> > >>> On 3/2/06, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > >>> > >>>> absolutely. I think for most cases the current implementation is > >> sufficient, > >>>> but for your high-rate of create/destroy of runtime instances I can > see > >> why > >>>> this might be a problem. > >>>> > >>>> WILL > >>>> > >>>> On 3/1/06, Serge Knystautas < [EMAIL PROTECTED]> wrote: > >>>> > >>>>> I did some memory profiling, and for each runtime instance, by > default > >>>>> it creates 20 parsers. According to yourkit, each parser uses just > >>>>> over 100kb heap space, so each runtime instance is costing me 2mb > heap > >>>>> space. > >>>>> > >>>>> I can simply reduce the # of parsers, but the problem is that simple > >>>>> pool is a very, very primitive pool implementation... it holds a > >>>>> constant number parsers and if you exceed, it simply creates and > >>>>> disposes a parser (ballpark of 1ms per parser instantiation in my > >>>>> benchmarks). > >>>>> > >>>>> I'd like to convert simplepool to an interface and then make the > >>>>> current behavior an impl so that you could swap in something like > >>>>> commons pool. Is there interest in such a patch? > >>>>> > >>>>> -- > >>>>> Serge Knystautas > >>>>> Lokitech >> software . strategy . design >> http://www.lokitech.com > >>>>> p. 301.656.5501 > >>>>> e. [EMAIL PROTECTED] > >>>>> > >>>>> > --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>> For additional commands, e-mail: > [EMAIL PROTECTED] > >>>>> > >>>>> > >>>> > >>>> -- > >>>> _______________________________________ > >>>> Forio Business Simulations > >>>> > >>>> Will Glass-Husain > >>>> phone (415) 440-7500 x89 > >>>> mobile (415) 235-4293 > >>>> [EMAIL PROTECTED] > >>>> www.forio.com > >>>> > >>>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > >> > >> > >> -- > >> > >> _______________________________________ > >> Forio Business Simulations > >> > >> Will Glass-Husain > >> phone (415) 440-7500 x89 > >> mobile (415) 235-4293 > >> [EMAIL PROTECTED] > >> www.forio.com > >> > > > > > > > > -- > > _______________________________________ > > Forio Business Simulations > > > > Will Glass-Husain > > phone (415) 440-7500 x89 > > mobile (415) 235-4293 > > [EMAIL PROTECTED] > > www.forio.com > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
-- _______________________________________ Forio Business Simulations Will Glass-Husain phone (415) 440-7500 x89 mobile (415) 235-4293 [EMAIL PROTECTED] www.forio.com
