On Fri, Nov 20, 2009 at 5:23 AM, Markus Kohler <[email protected]>wrote:
> Hi all, > Just as a teaser ;-) > The textile support is expensive in regards to the memory allocated (freed > afterwards). > Details will come as soon as I find some time. > Yeah. Lift's Textile parser using Scala's parser combinator library... it's low and memory intensive. Anyone want to sign up to re-write it? ;-) > > Regards, > Markus > > On Fri, Nov 20, 2009 at 1:58 PM, Vassil Dichev <[email protected]> wrote: > > > I just wanted to say thanks to Markus for doing this, and I think > > performance testing is a critical aspect for this type of application > > (as Twitter have demonstrated very convincingly). > > > > I also believe performance testing of ESME is also a great way to test > > Lift, as ESME is one of the biggest open-source projects using Lift > > (ok, there aren't many anyway). Other bugs which performance tests > > could catch would be deadlocks and thread contention, and these are > > vitally important in the light of the dynamic change Lift is > > undergoing swapping its actor implementations. > > > > It's also a good idea to run performance tests on Hudson, at least for > > the time being- we don't have that many commits per week yet. > > > > About memory analysis being a low-hanging fruit: agree 100%, provided > > one condition is fulfilled. The condition is that we're able to test > > the application locally, and performance tests help us do exactly > > that. Previously many bugs could only be reproduced by everyone on the > > Stax instance. Besides, a long time ago I have worked on memory leak > > problems in the same area as Markus, so I think we have enough > > know-how. > > > > Vassil > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics
