Re: Further analysis of the GC issue

Thanks, I will try that. Markus The best way to predict the future is to invent it -- Alan Kay On Thu, Nov 26, 2009 at 10:09 AM, Richard Hirsch hirsch.d...@gmail.comwrote: @Markus It would be interesting to remove the Textile parser and do the tests again. This would confirm whether it is

Re: Further analysis of the GC issue

@Markus It would be interesting to remove the Textile parser and do the tests again. This would confirm whether it is the culprit or not. If I remember correctly, it was just a change in one line of code. Just found the change

Re: Further analysis of the GC issue

Good idea about having the user decide what parser to use. I'm also assuming that bold and italic should be enough On Thu, Nov 26, 2009 at 10:25 AM, Vassil Dichev vdic...@apache.org wrote: @Markus It would be interesting to remove the Textile parser and do the tests again. This would confirm

Re: Further analysis of the GC issue

@Michael: A couple of weeks ago we had a very interesting discussion ref sessions and RESTful APIs. If you find the time, I suggest you read it as it does a good job explaining ESME's design. http://www.mail-archive.com/esme-dev%40incubator.apache.org/msg01766.html (Read the mails which

Re: Further analysis of the GC issue

@Michael: A couple of weeks ago we had a very interesting discussion ref sessions and RESTful APIs. If you find the time, I suggest you read it as it does a good job explaining ESME's design. http://www.mail-archive.com/esme-dev%40incubator.apache.org/msg01766.html (Read the mails which

Re: Further analysis of the GC issue

Hi Vassil, Great! *bold* and _italic_ are IMHO the most important features. Simple lists could be next, but a quick sample of stackoverlow shows people don't use anything elsen then bold and italic (and code formatting). Regards, Markus The best way to predict the future is to invent it -- Alan

Re: Further analysis of the GC issue

It has been on my to-do list for ages...can someone please give me 48 hour days soon? ;) This weekend will be an ESME weekend for me (UI), I will get something started about our design philosophy on the wiki. On 26. nov. 2009, at 11.00, Vassil Dichev wrote: @Michael: A couple of weeks ago

Re: Further analysis of the GC issue

http://cwiki.apache.org/confluence/display/ESME/Our+Design+Philosophy I'll add content to it this afternoon. Any ideas of a basic structure. *Importance of streaming... D. On Thu, Nov 26, 2009 at 11:08 AM, Richard Hirsch hirsch.d...@gmail.com wrote: @Anne: UI is more impt. I'll add a design

Re: Further analysis of the GC issue

Can't wait to see th new UI in action :-) Markus The best way to predict the future is to invent it -- Alan Kay On Thu, Nov 26, 2009 at 11:07 AM, Anne Kathrine Petterøe akpette...@gmail.com wrote: It has been on my to-do list for ages...can someone please give me 48 hour days soon? ;) This

Re: Further analysis of the GC issue

Can't wait to see th new UI in action :-) ++1 @Anne no pressure :- On Thu, Nov 26, 2009 at 11:19 AM, Markus Kohler markus.koh...@gmail.com wrote: Can't wait to see th new UI in action :-) Markus The best way to

Re: Further analysis of the GC issue

OMG! Right, no pressure at all LOL On 26. nov. 2009, at 13.38, Richard Hirsch wrote: Can't wait to see th new UI in action :-) + +1 @Anne no pressure :- On Thu, Nov 26, 2009 at 11:19 AM, Markus Kohler

Removing textile from code base

I think it might be a good idea if we removed the textile parsing - especially if it is really causing such a performance hit. @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

RE: Further analysis of the GC issue

Thanks Markus. That certainly sounds much better. I was confused yesterday already because 23 GByte memory would be a little difficult to create when not even the operating system can handle such size. I should have asked right away. Blame it on jetlag. -Michael -Original Message- From:

Re: Removing textile from code base

@Vassil Thanks - just saw the commit D. On Thu, Nov 26, 2009 at 1:55 PM, Richard Hirsch hirsch.d...@gmail.com 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. @Vassil: Could you remove the textile parser

Re: Further analysis of the GC issue

Hi Michael, No problem :-) Regards, Markus The best way to predict the future is to invent it -- Alan Kay On Thu, Nov 26, 2009 at 2:12 PM, Bechauf, Michael michael.bech...@sap.comwrote: Thanks Markus. That certainly sounds much better. I was confused yesterday already because 23 GByte

Re: Removing textile from code base

@Vassil Thanks - just saw the commit I was just going to write that I'm done- now we parse for *strong* and _emph_ ourselves. You can deploy when you're ready and I'm eager for the others to try it, especially Markus ;-)

Re: Removing textile from code base

On Thu, Nov 26, 2009 at 4:55 AM, Richard Hirsch hirsch.d...@gmail.comwrote: 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

Re: Removing textile from code base

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

Re: Removing textile from code base

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

Re: Removing textile from code base

I'm wrong about the PublicTimeline. It is cached (just not the same place as a user's Timeline). And it is updated in real-time, too. Both timelines use Message.findMessages, which uses a LRU. There are places where checking the permissions via the access pools could be optimized, but doesn't

Re: Removing textile from code base

Regarding the public timeline, it is on a different page on the new UI, so this might solve some of our problems. D. On Thu, Nov 26, 2009 at 3:41 PM, Vassil Dichev vdic...@apache.org wrote: We're not looking at the root cause of the problem.  The Textile stuff is a hit if we run it on each

Re: Removing textile from code base

Regarding the public timeline, it is on a different page on the new UI, so this might solve some of our problems. I think it's just jQuery juggling with DOM elements, giving the impression it's a different page. The url shows that it's still loaded the first time it's accessed. The advantage is

Re: Further analysis of the GC issue

Moved this whole thread to the wiki: http://cwiki.apache.org/confluence/display/ESME/Performance+test+2009-11-25 D. On Thu, Nov 26, 2009 at 2:22 PM, Markus Kohler markus.koh...@gmail.com wrote: Hi Michael, No problem :-) Regards, Markus The best way to predict the future is to invent it

Re: Further analysis of the GC issue

Started adding content to the Design Philosophy page: http://cwiki.apache.org/confluence/display/ESME/Our+Design+Philosophy On Thu, Nov 26, 2009 at 11:10 AM, Richard Hirsch hirsch.d...@gmail.com wrote: http://cwiki.apache.org/confluence/display/ESME/Our+Design+Philosophy I'll add content to it

Re: Further analysis of the GC issue

I've tried some optimizations. The conversion of messages to JSON was not lazy, which was a sign that I was at the time I wrote it :) This conversion is necessary for the main timeline, since JSON is the format it communicates with jQuery for live updates. I've also chosen the lesser of two evils