June 2008 - Dillo-dev - lists.mailman3.com

Textblock::addText()

by Johannes.Hofmann＠gmx.de

On Sat, Jun 21, 2008 at 02:38:48PM -0400, Jorge Arellano Cid wrote: > On Sat, Jun 21, 2008 at 06:23:18PM +0200, Johannes Hofmann wrote: > > On Sat, Jun 21, 2008 at 11:31:56AM -0400, Jorge Arellano Cid wrote: > > > On Fri, Jun 20, 2008 at 08:45:18PM +0200, Johannes Hofmann wrote: > > > > Hi, > > > > > > > > On Fri, Jun 20, 2008 at 01:03:26PM -0400, Jorge Arellano Cid wrote: > > > > > Hi there, > > > > > > > > > > - Changed Textblock::addText() to internally allocate its text string, > > > > > making the memory handling opaque to the caller. > > > > > > > > > > Does anybody remmeber the topic of addText() deleting a malloc'ed > > > > > block of memory? > > > > > > > > > > I decided to make the change for API cleanliness/correctness and set > > > > > the Textblock do the whole memory handling (i.e. now the Textblock is > > > > > the one that allocates/deallocates the text string). > > > > > > > > > > The HTML parser was adjusted a bit to keep its old performance. > > > > > > > > Very nice! > > > > I thought this is the right moment to drag out my old text > > > > allocation optimization. > > > > And now it really makes a difference. > > > > I see about 10M less memory usage on the mysql page and most > > > > important, leaving that huge page is quite a bit faster - as there > > > > is less free() calls. > > > > The result may be completely different on Linux however. So please > > > > give it a try on Linux. > > > > > > Here I have: > > > > > > Platform: Debian GNU/Linux, dillo-fltk with image_off > > > Test : huge mysql page > > > > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > > > 0.1 9672 4144 pts/10 S+ 08:51 0:00 ./dillo-fltk.21Jun > > > 5.9 147588 123896 pts/10 S+ 08:51 0:02 ./dillo-fltk.21Jun > > > > > > 0.1 9676 4136 pts/17 S+ 08:54 0:00 ./dillo-fltk > > > 5.4 136684 112872 pts/17 S+ 08:54 0:02 ./dillo-fltk > > > > > > This is roughly 10% of memory usage reduction. > > > > > > Committed. > > > > In this case I have a little cleanup. > > This patch also avoids one strlen() per added word. > > How much is the speed gain? I can't see much of a difference. I'm trying with: --- a/src/html.ccSat Jun 21 15:00:35 2008 +0200 +++ b/src/html.ccSat Jun 21 22:27:30 2008 +0200 @@ -672,6 +672,7 @@ void DilloHtml::finishParsing(int Client freeParseData(); parse_finished = true; +exit(0); } /* and then time dillo-fltk manual.html, but the numbers are varying greatly - at least more than the speed gain, if there is any. Do you know a better method to measure the performance? perhaps parsing the document 10 times in a loop? > > I hesitate because this adds the overhead of one extra > parameter per word. Well, let's look at the numbers. > > You can test by overloading addText and changing the html.cc:1195 call. Cheers, Johannes

June 21, 2008

Textblock::addText()

by jcid＠dillo.org

On Sat, Jun 21, 2008 at 06:23:18PM +0200, Johannes Hofmann wrote: > On Sat, Jun 21, 2008 at 11:31:56AM -0400, Jorge Arellano Cid wrote: > > On Fri, Jun 20, 2008 at 08:45:18PM +0200, Johannes Hofmann wrote: > > > Hi, > > > > > > On Fri, Jun 20, 2008 at 01:03:26PM -0400, Jorge Arellano Cid wrote: > > > > Hi there, > > > > > > > > - Changed Textblock::addText() to internally allocate its text string, > > > > making the memory handling opaque to the caller. > > > > > > > > Does anybody remmeber the topic of addText() deleting a malloc'ed > > > > block of memory? > > > > > > > > I decided to make the change for API cleanliness/correctness and set > > > > the Textblock do the whole memory handling (i.e. now the Textblock is > > > > the one that allocates/deallocates the text string). > > > > > > > > The HTML parser was adjusted a bit to keep its old performance. > > > > > > Very nice! > > > I thought this is the right moment to drag out my old text > > > allocation optimization. > > > And now it really makes a difference. > > > I see about 10M less memory usage on the mysql page and most > > > important, leaving that huge page is quite a bit faster - as there > > > is less free() calls. > > > The result may be completely different on Linux however. So please > > > give it a try on Linux. > > > > Here I have: > > > > Platform: Debian GNU/Linux, dillo-fltk with image_off > > Test : huge mysql page > > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > > 0.1 9672 4144 pts/10 S+ 08:51 0:00 ./dillo-fltk.21Jun > > 5.9 147588 123896 pts/10 S+ 08:51 0:02 ./dillo-fltk.21Jun > > > > 0.1 9676 4136 pts/17 S+ 08:54 0:00 ./dillo-fltk > > 5.4 136684 112872 pts/17 S+ 08:54 0:02 ./dillo-fltk > > > > This is roughly 10% of memory usage reduction. > > > > Committed. > > In this case I have a little cleanup. > This patch also avoids one strlen() per added word. How much is the speed gain? I hesitate because this adds the overhead of one extra parameter per word. Well, let's look at the numbers. You can test by overloading addText and changing the html.cc:1195 call. -- Cheers Jorge.-

June 21, 2008

Textblock::addText()

by Johannes.Hofmann＠gmx.de

On Sat, Jun 21, 2008 at 11:31:56AM -0400, Jorge Arellano Cid wrote: > On Fri, Jun 20, 2008 at 08:45:18PM +0200, Johannes Hofmann wrote: > > Hi, > > > > On Fri, Jun 20, 2008 at 01:03:26PM -0400, Jorge Arellano Cid wrote: > > > Hi there, > > > > > > - Changed Textblock::addText() to internally allocate its text string, > > > making the memory handling opaque to the caller. > > > > > > Does anybody remmeber the topic of addText() deleting a malloc'ed > > > block of memory? > > > > > > I decided to make the change for API cleanliness/correctness and set > > > the Textblock do the whole memory handling (i.e. now the Textblock is > > > the one that allocates/deallocates the text string). > > > > > > The HTML parser was adjusted a bit to keep its old performance. > > > > Very nice! > > I thought this is the right moment to drag out my old text > > allocation optimization. > > And now it really makes a difference. > > I see about 10M less memory usage on the mysql page and most > > important, leaving that huge page is quite a bit faster - as there > > is less free() calls. > > The result may be completely different on Linux however. So please > > give it a try on Linux. > > Here I have: > > Platform: Debian GNU/Linux, dillo-fltk with image_off > Test : huge mysql page > > %MEM VSZ RSS TTY STAT START TIME COMMAND > 0.1 9672 4144 pts/10 S+ 08:51 0:00 ./dillo-fltk.21Jun > 5.9 147588 123896 pts/10 S+ 08:51 0:02 ./dillo-fltk.21Jun > > 0.1 9676 4136 pts/17 S+ 08:54 0:00 ./dillo-fltk > 5.4 136684 112872 pts/17 S+ 08:54 0:02 ./dillo-fltk > > This is roughly 10% of memory usage reduction. > > Committed. In this case I have a little cleanup. This patch also avoids one strlen() per added word. Cheers, Johannes

June 21, 2008

Textblock::addText()

by jcid＠dillo.org

On Sat, Jun 21, 2008 at 11:31:56AM -0400, Jorge Arellano Cid wrote: > Here I have: > > Platform: Debian GNU/Linux, dillo-fltk with image_off > Test : huge mysql page > > %MEM VSZ RSS TTY STAT START TIME COMMAND > 0.1 9672 4144 pts/10 S+ 08:51 0:00 ./dillo-fltk.21Jun > 5.9 147588 123896 pts/10 S+ 08:51 0:02 ./dillo-fltk.21Jun > > 0.1 9676 4136 pts/17 S+ 08:54 0:00 ./dillo-fltk > 5.4 136684 112872 pts/17 S+ 08:54 0:02 ./dillo-fltk > > This is roughly 10% of memory usage reduction. > > Committed. BTW, here there is no noticeable speedup on leaving the page, and it is quite fast. -- Cheers Jorge.-

June 21, 2008

Textblock::addText()

by jcid＠dillo.org

On Fri, Jun 20, 2008 at 08:45:18PM +0200, Johannes Hofmann wrote: > Hi, > > On Fri, Jun 20, 2008 at 01:03:26PM -0400, Jorge Arellano Cid wrote: > > Hi there, > > > > - Changed Textblock::addText() to internally allocate its text string, > > making the memory handling opaque to the caller. > > > > Does anybody remmeber the topic of addText() deleting a malloc'ed > > block of memory? > > > > I decided to make the change for API cleanliness/correctness and set > > the Textblock do the whole memory handling (i.e. now the Textblock is > > the one that allocates/deallocates the text string). > > > > The HTML parser was adjusted a bit to keep its old performance. > > Very nice! > I thought this is the right moment to drag out my old text > allocation optimization. > And now it really makes a difference. > I see about 10M less memory usage on the mysql page and most > important, leaving that huge page is quite a bit faster - as there > is less free() calls. > The result may be completely different on Linux however. So please > give it a try on Linux. Here I have: Platform: Debian GNU/Linux, dillo-fltk with image_off Test : huge mysql page %MEM VSZ RSS TTY STAT START TIME COMMAND 0.1 9672 4144 pts/10 S+ 08:51 0:00 ./dillo-fltk.21Jun 5.9 147588 123896 pts/10 S+ 08:51 0:02 ./dillo-fltk.21Jun 0.1 9676 4136 pts/17 S+ 08:54 0:00 ./dillo-fltk 5.4 136684 112872 pts/17 S+ 08:54 0:02 ./dillo-fltk This is roughly 10% of memory usage reduction. Committed. -- Cheers Jorge.-

June 21, 2008

Splitting html.cc: what next?

by jcid＠dillo.org

On Fri, Jun 20, 2008 at 09:26:32PM +0100, Jeremy Henty wrote: > [...] > Fair enough. What was the decision about splitting off table.cc ? I > sent in the patch but it hasn't appeared in CVS and I've not seen a > response. I don't particularly mind either way, but it would be > useful to know whether it's going to happen. Ooops, I skipped over it unintentionally. Thanks for the reminder. Committed. -- Cheers Jorge.-

June 21, 2008

occasional bus errors

by Johannes.Hofmann＠gmx.de

On Fri, Jun 20, 2008 at 09:17:22PM +0100, Jeremy Henty wrote: > On Fri, Jun 20, 2008 at 05:49:13PM +0200, Johannes Hofmann wrote: > > > > is anyone else seeing these rare bus errors? This is not new and > > happens every now and then. I'm trying to track it down, but it > > would be helpful to have a method to reliably reproduce it. > > I have one core dump saved that has the same stack trace, except that > mine continues past ~DeepIterator() into ~Stack() and then gets > "signal 11, Segmentation fault.". This is on Linux. Could it be the > same bug with platform-dependent effects? > > I am afraid I didn't investigate much further and couldn't get it to > happen reliably. My memory is that the crash occurred immediately > after dragging and releasing a selection. Is that when your bus > errors happen? I can't reproduce it either but from the stack it's related to the selection code. I'm not 100% sure but it may well be that I also had segmentation faults with similar stacks. I think we are seeing the same problem. Regards, Johannes

June 20, 2008

Splitting html.cc: what next?

by onepoint＠starurchin.org

On Thu, Jun 19, 2008 at 12:26:10PM -0400, Jorge Arellano Cid wrote: > On Wed, Jun 11, 2008 at 06:49:39PM +0100, Jeremy Henty wrote: > > On Wed, Jun 11, 2008 at 12:13:13PM -0400, Jorge Arellano Cid wrote: > > > > > I'd say go with table... ...and that's it. > > > > :-( I was looking forward to more slicing and dicing! ;-) > > You can keep on polishing! Actually, I think I've done most of the easy polishing for the moment. I might actually have to fix something! :-) > It's just we _may_ need to change some of the parser structure in > the future and I didn't want you to polish it throughly and then see > it re-structured into something different. Fair enough. What was the decision about splitting off table.cc ? I sent in the patch but it hasn't appeared in CVS and I've not seen a response. I don't particularly mind either way, but it would be useful to know whether it's going to happen. Regards, Jeremy Henty

June 20, 2008

occasional bus errors

by onepoint＠starurchin.org

On Fri, Jun 20, 2008 at 05:49:13PM +0200, Johannes Hofmann wrote: > > is anyone else seeing these rare bus errors? This is not new and > happens every now and then. I'm trying to track it down, but it > would be helpful to have a method to reliably reproduce it. I have one core dump saved that has the same stack trace, except that mine continues past ~DeepIterator() into ~Stack() and then gets "signal 11, Segmentation fault.". This is on Linux. Could it be the same bug with platform-dependent effects? I am afraid I didn't investigate much further and couldn't get it to happen reliably. My memory is that the crash occurred immediately after dragging and releasing a selection. Is that when your bus errors happen? Regards, Jeremy Henty

June 20, 2008

occasional bus errors

by jcid＠dillo.org

On Fri, Jun 20, 2008 at 04:13:20PM +0000, corvid wrote: > Johannes wrote: > > is anyone else seeing these rare bus errors? This is not new and > > happens every now and then. I'm trying to track it down, but it > > would be helpful to have a method to reliably reproduce it. > > No, I haven't been seeing them here on linux. Neither me, ever. -- Cheers Jorge.-

June 20, 2008