You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by Markus Kohler <ma...@gmail.com> on 2009/11/24 00:30:07 UTC
Memory allocation analysis
Hi all,
I just sent Richard the brief memory allocation analysis. It doesn't make
sense to post it here without attachements.
The short summary is, that I don't think it makes sense to put a lot of work
into optimizing it.
Markus
"The best way to predict the future is to invent it" -- Alan Kay
Re: Memory allocation analysis
Posted by Richard Hirsch <hi...@gmail.com>.
Added all details to the wiki page.
D.
On Tue, Nov 24, 2009 at 11:45 AM, Markus Kohler <ma...@gmail.com> wrote:
> Hi Richard,
>
> one correction I set the max heap size to 256Mbyte. At the moment that is
> more than in enough and makes it comparable to the STAX environment.
>
> We should add the JVM options from now on. I used "-Xmx256m" and
> "-Xloggc:gc.txt"
> (for being able to visualize the GC log with
> http://www.tagtraum.com/gcviewer.html).
> I will add more options over time.
>
> BTW, I used build #15 from hudson. I will update to a newer one ASAP.
>
>
> Regards,
> Markus
>
> "The best way to predict the future is to invent it" -- Alan Kay
>
>
> On Tue, Nov 24, 2009 at 11:20 AM, Richard Hirsch <hi...@gmail.com>wrote:
>
>> Posted the performance results (plus attachments) to the wiki:
>>
>> http://cwiki.apache.org/confluence/display/ESME/Performance+test+2009-11-24
>>
>> D.
>>
>> On Tue, Nov 24, 2009 at 10:48 AM, Markus Kohler <ma...@gmail.com>
>> wrote:
>> > Hi Vassil,
>> > OK I understand, for automatically generated messages a server side
>> > implementation would be needed.
>> >
>> >
>> > Markus
>> > "The best way to predict the future is to invent it" -- Alan Kay
>> >
>> >
>> > On Tue, Nov 24, 2009 at 10:17 AM, Vassil Dichev <vd...@apache.org>
>> wrote:
>> >
>> >> > Basically I meant that we should just go for a simple custom formatter
>> >> and
>> >> > not try to improve the existing textile formatter.
>> >>
>> >> Agreed. It will be easiest to first add just enough formatting
>> >> necessary for the needs of ESME and then think about full-blown
>> >> parsers. Not that the latter is not worth investing in, but it will
>> >> take more effort.
>> >>
>> >> > David suggested ANTLR and maybe we should give it a try and write a
>> >> custom
>> >> > formatter.
>> >>
>> >> ANTLR would be nice for something where speed is important and parsing
>> >> is complex, like parsing scala syntax in a beautifier. For an
>> >> occasional comment in a blog liftweb-textile should be OK, I guess.
>> >>
>> >> > Another crazy idea that just came to my mind would be to use
>> javascript
>> >> on
>> >> > the client side to do the formatting. Not sure whether this could be
>> >> easily
>> >> > support all the features ESME needs, but markdown formatting using
>> >> > javascript is possible :
>> >> >
>> >>
>> http://stackoverflow.com/questions/1319657/javascript-to-convert-markdown-textile-to-html-and-ideally-back-to-markdown-te
>> >> > points to http://attacklab.net/showdown/
>> >> >
>> >> > Stackoverflow itself does on the fly formatting, which I think is a
>> nifty
>> >> > feature.
>> >>
>> >> This is not a crazy idea at all, however I had the idea to apply
>> >> formatting to automatically generated messages, and not based on
>> >> lightweight formatting rules only.
>> >>
>> >
>>
>
Re: Memory allocation analysis
Posted by Markus Kohler <ma...@gmail.com>.
Hi Richard,
one correction I set the max heap size to 256Mbyte. At the moment that is
more than in enough and makes it comparable to the STAX environment.
We should add the JVM options from now on. I used "-Xmx256m" and
"-Xloggc:gc.txt"
(for being able to visualize the GC log with
http://www.tagtraum.com/gcviewer.html).
I will add more options over time.
BTW, I used build #15 from hudson. I will update to a newer one ASAP.
Regards,
Markus
"The best way to predict the future is to invent it" -- Alan Kay
On Tue, Nov 24, 2009 at 11:20 AM, Richard Hirsch <hi...@gmail.com>wrote:
> Posted the performance results (plus attachments) to the wiki:
>
> http://cwiki.apache.org/confluence/display/ESME/Performance+test+2009-11-24
>
> D.
>
> On Tue, Nov 24, 2009 at 10:48 AM, Markus Kohler <ma...@gmail.com>
> wrote:
> > Hi Vassil,
> > OK I understand, for automatically generated messages a server side
> > implementation would be needed.
> >
> >
> > Markus
> > "The best way to predict the future is to invent it" -- Alan Kay
> >
> >
> > On Tue, Nov 24, 2009 at 10:17 AM, Vassil Dichev <vd...@apache.org>
> wrote:
> >
> >> > Basically I meant that we should just go for a simple custom formatter
> >> and
> >> > not try to improve the existing textile formatter.
> >>
> >> Agreed. It will be easiest to first add just enough formatting
> >> necessary for the needs of ESME and then think about full-blown
> >> parsers. Not that the latter is not worth investing in, but it will
> >> take more effort.
> >>
> >> > David suggested ANTLR and maybe we should give it a try and write a
> >> custom
> >> > formatter.
> >>
> >> ANTLR would be nice for something where speed is important and parsing
> >> is complex, like parsing scala syntax in a beautifier. For an
> >> occasional comment in a blog liftweb-textile should be OK, I guess.
> >>
> >> > Another crazy idea that just came to my mind would be to use
> javascript
> >> on
> >> > the client side to do the formatting. Not sure whether this could be
> >> easily
> >> > support all the features ESME needs, but markdown formatting using
> >> > javascript is possible :
> >> >
> >>
> http://stackoverflow.com/questions/1319657/javascript-to-convert-markdown-textile-to-html-and-ideally-back-to-markdown-te
> >> > points to http://attacklab.net/showdown/
> >> >
> >> > Stackoverflow itself does on the fly formatting, which I think is a
> nifty
> >> > feature.
> >>
> >> This is not a crazy idea at all, however I had the idea to apply
> >> formatting to automatically generated messages, and not based on
> >> lightweight formatting rules only.
> >>
> >
>
Re: Memory allocation analysis
Posted by Markus Kohler <ma...@gmail.com>.
Thanks!
Markus
"The best way to predict the future is to invent it" -- Alan Kay
On Tue, Nov 24, 2009 at 11:20 AM, Richard Hirsch <hi...@gmail.com>wrote:
> Posted the performance results (plus attachments) to the wiki:
>
> http://cwiki.apache.org/confluence/display/ESME/Performance+test+2009-11-24
>
> D.
>
> On Tue, Nov 24, 2009 at 10:48 AM, Markus Kohler <ma...@gmail.com>
> wrote:
> > Hi Vassil,
> > OK I understand, for automatically generated messages a server side
> > implementation would be needed.
> >
> >
> > Markus
> > "The best way to predict the future is to invent it" -- Alan Kay
> >
> >
> > On Tue, Nov 24, 2009 at 10:17 AM, Vassil Dichev <vd...@apache.org>
> wrote:
> >
> >> > Basically I meant that we should just go for a simple custom formatter
> >> and
> >> > not try to improve the existing textile formatter.
> >>
> >> Agreed. It will be easiest to first add just enough formatting
> >> necessary for the needs of ESME and then think about full-blown
> >> parsers. Not that the latter is not worth investing in, but it will
> >> take more effort.
> >>
> >> > David suggested ANTLR and maybe we should give it a try and write a
> >> custom
> >> > formatter.
> >>
> >> ANTLR would be nice for something where speed is important and parsing
> >> is complex, like parsing scala syntax in a beautifier. For an
> >> occasional comment in a blog liftweb-textile should be OK, I guess.
> >>
> >> > Another crazy idea that just came to my mind would be to use
> javascript
> >> on
> >> > the client side to do the formatting. Not sure whether this could be
> >> easily
> >> > support all the features ESME needs, but markdown formatting using
> >> > javascript is possible :
> >> >
> >>
> http://stackoverflow.com/questions/1319657/javascript-to-convert-markdown-textile-to-html-and-ideally-back-to-markdown-te
> >> > points to http://attacklab.net/showdown/
> >> >
> >> > Stackoverflow itself does on the fly formatting, which I think is a
> nifty
> >> > feature.
> >>
> >> This is not a crazy idea at all, however I had the idea to apply
> >> formatting to automatically generated messages, and not based on
> >> lightweight formatting rules only.
> >>
> >
>
Re: Memory allocation analysis
Posted by Richard Hirsch <hi...@gmail.com>.
Posted the performance results (plus attachments) to the wiki:
http://cwiki.apache.org/confluence/display/ESME/Performance+test+2009-11-24
D.
On Tue, Nov 24, 2009 at 10:48 AM, Markus Kohler <ma...@gmail.com> wrote:
> Hi Vassil,
> OK I understand, for automatically generated messages a server side
> implementation would be needed.
>
>
> Markus
> "The best way to predict the future is to invent it" -- Alan Kay
>
>
> On Tue, Nov 24, 2009 at 10:17 AM, Vassil Dichev <vd...@apache.org> wrote:
>
>> > Basically I meant that we should just go for a simple custom formatter
>> and
>> > not try to improve the existing textile formatter.
>>
>> Agreed. It will be easiest to first add just enough formatting
>> necessary for the needs of ESME and then think about full-blown
>> parsers. Not that the latter is not worth investing in, but it will
>> take more effort.
>>
>> > David suggested ANTLR and maybe we should give it a try and write a
>> custom
>> > formatter.
>>
>> ANTLR would be nice for something where speed is important and parsing
>> is complex, like parsing scala syntax in a beautifier. For an
>> occasional comment in a blog liftweb-textile should be OK, I guess.
>>
>> > Another crazy idea that just came to my mind would be to use javascript
>> on
>> > the client side to do the formatting. Not sure whether this could be
>> easily
>> > support all the features ESME needs, but markdown formatting using
>> > javascript is possible :
>> >
>> http://stackoverflow.com/questions/1319657/javascript-to-convert-markdown-textile-to-html-and-ideally-back-to-markdown-te
>> > points to http://attacklab.net/showdown/
>> >
>> > Stackoverflow itself does on the fly formatting, which I think is a nifty
>> > feature.
>>
>> This is not a crazy idea at all, however I had the idea to apply
>> formatting to automatically generated messages, and not based on
>> lightweight formatting rules only.
>>
>
Re: Memory allocation analysis
Posted by Markus Kohler <ma...@gmail.com>.
Hi Vassil,
OK I understand, for automatically generated messages a server side
implementation would be needed.
Markus
"The best way to predict the future is to invent it" -- Alan Kay
On Tue, Nov 24, 2009 at 10:17 AM, Vassil Dichev <vd...@apache.org> wrote:
> > Basically I meant that we should just go for a simple custom formatter
> and
> > not try to improve the existing textile formatter.
>
> Agreed. It will be easiest to first add just enough formatting
> necessary for the needs of ESME and then think about full-blown
> parsers. Not that the latter is not worth investing in, but it will
> take more effort.
>
> > David suggested ANTLR and maybe we should give it a try and write a
> custom
> > formatter.
>
> ANTLR would be nice for something where speed is important and parsing
> is complex, like parsing scala syntax in a beautifier. For an
> occasional comment in a blog liftweb-textile should be OK, I guess.
>
> > Another crazy idea that just came to my mind would be to use javascript
> on
> > the client side to do the formatting. Not sure whether this could be
> easily
> > support all the features ESME needs, but markdown formatting using
> > javascript is possible :
> >
> http://stackoverflow.com/questions/1319657/javascript-to-convert-markdown-textile-to-html-and-ideally-back-to-markdown-te
> > points to http://attacklab.net/showdown/
> >
> > Stackoverflow itself does on the fly formatting, which I think is a nifty
> > feature.
>
> This is not a crazy idea at all, however I had the idea to apply
> formatting to automatically generated messages, and not based on
> lightweight formatting rules only.
>
Re: Memory allocation analysis
Posted by Vassil Dichev <vd...@apache.org>.
> Basically I meant that we should just go for a simple custom formatter and
> not try to improve the existing textile formatter.
Agreed. It will be easiest to first add just enough formatting
necessary for the needs of ESME and then think about full-blown
parsers. Not that the latter is not worth investing in, but it will
take more effort.
> David suggested ANTLR and maybe we should give it a try and write a custom
> formatter.
ANTLR would be nice for something where speed is important and parsing
is complex, like parsing scala syntax in a beautifier. For an
occasional comment in a blog liftweb-textile should be OK, I guess.
> Another crazy idea that just came to my mind would be to use javascript on
> the client side to do the formatting. Not sure whether this could be easily
> support all the features ESME needs, but markdown formatting using
> javascript is possible :
> http://stackoverflow.com/questions/1319657/javascript-to-convert-markdown-textile-to-html-and-ideally-back-to-markdown-te
> points to http://attacklab.net/showdown/
>
> Stackoverflow itself does on the fly formatting, which I think is a nifty
> feature.
This is not a crazy idea at all, however I had the idea to apply
formatting to automatically generated messages, and not based on
lightweight formatting rules only.
Re: Memory allocation analysis
Posted by Markus Kohler <ma...@gmail.com>.
Hi,
Sorry of be brief yesterday. I was too tired I guess.
Basically I meant that we should just go for a simple custom formatter and
not try to improve the existing textile formatter.
Optimizing the textile formatter would probably mean optimizing the Scala
parser combinator in general, which is probably hard and risky, because all
parsers written using the combinator would still have to work.
David suggested ANTLR and maybe we should give it a try and write a custom
formatter.
Another crazy idea that just came to my mind would be to use javascript on
the client side to do the formatting. Not sure whether this could be easily
support all the features ESME needs, but markdown formatting using
javascript is possible :
http://stackoverflow.com/questions/1319657/javascript-to-convert-markdown-textile-to-html-and-ideally-back-to-markdown-te
points to http://attacklab.net/showdown/
Stackoverflow itself does on the fly formatting, which I think is a nifty
feature.
Regards,
Markus
Regards,
Markus
"The best way to predict the future is to invent it" -- Alan Kay
On Tue, Nov 24, 2009 at 6:45 AM, Richard Hirsch <hi...@gmail.com>wrote:
> @Markus: Why doesn't it make sense to optimize it?
>
> D.
>
> On Tue, Nov 24, 2009 at 12:30 AM, Markus Kohler <ma...@gmail.com>
> wrote:
> > Hi all,
> > I just sent Richard the brief memory allocation analysis. It doesn't make
> > sense to post it here without attachements.
> > The short summary is, that I don't think it makes sense to put a lot of
> work
> > into optimizing it.
> >
> > Markus
> >
> > "The best way to predict the future is to invent it" -- Alan Kay
> >
>
Re: Memory allocation analysis
Posted by Richard Hirsch <hi...@gmail.com>.
@Markus: Why doesn't it make sense to optimize it?
D.
On Tue, Nov 24, 2009 at 12:30 AM, Markus Kohler <ma...@gmail.com> wrote:
> Hi all,
> I just sent Richard the brief memory allocation analysis. It doesn't make
> sense to post it here without attachements.
> The short summary is, that I don't think it makes sense to put a lot of work
> into optimizing it.
>
> Markus
>
> "The best way to predict the future is to invent it" -- Alan Kay
>