Hi David, you are right the main problem ATM is not the textile parser. But for a small number of users, I would expect that replacing the parser would help to get better performance for now.
Regards, Markus "The best way to predict the future is to invent it" -- Alan Kay On Thu, Nov 26, 2009 at 2:36 PM, David Pollak <[email protected] > wrote: > On Thu, Nov 26, 2009 at 4:55 AM, Richard Hirsch <[email protected] > >wrote: > > > I think it might be a good idea if we removed the textile parsing - > > especially if it is really causing such a performance hit. > > > > We're not looking at the root cause of the problem. The Textile stuff is a > hit if we run it on each message for each user. This is no different than > having an SQL query in the code that's a Cartesian product and throwing out > SQL because of it. > > Let's find out where and why we keep loading the same message from the > RDBMS > rather than going to the message cache. > > Let's find out why we're hitting the RDBMS in general... there are > abstractions in the system (or at least were) that make RDBMS access a > local > thing rather than a global thing. > > I'll have time on Monday to look at this, but running around chopping off > pieces of code and changing functionality isn't going to get us any closer > to solving the problem... it's just going to cause the problem to be > manifest elsewhere. > > > > > > @Vassil: Could you remove the textile parser from the code and replace > > it with the old parsing functionality. If I remember correctly, there > > are multiple places in the code base were it is present. The best > > would be to comment out the Textile code so that we remember were it > > was in the code base. If you do this today, I could do a deployment > > on Stax tomorrow so that it could be tested by the whole community. > > > > D. > > > > > > -- > 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 >
