- Dillo-dev - lists.mailman3.com

patch: (any Solarians in the audience?) rm nanosleep solaris workaround

by jcid＠dillo.org

On Tue, Jul 01, 2008 at 09:57:59PM +0000, corvid wrote: > It seems that there was a nanosleep() in src/IO/dpi.c long ago, > but I can't find any nanosleep()s anywhere anymore, so... Committed. Let's hope for somebody to have FLTK2 and dillo2 in Solaris! :) -- Cheers Jorge.-

July 3, 2008

iterator related bugs

by jcid＠dillo.org

On Wed, Jul 02, 2008 at 09:11:12PM +0200, Johannes Hofmann wrote: > Hi, > > while looking for the reason of the rare selection related crashes I > found something that seems like a severe bunch of bugs in the > iterator code. > It might be related to the crash, but I'm not 100% sure yet. > > There is this innocent comment in front of the DeepIterator > constructor in iterator.cc: > > If you want to continue using \em it, pass it->cloneIterator(). > > This means, that the DeepIterator constructor eats up the Iterator it > get's passed a pointer to! > > The evil thing is that every method that passes one of it's > arguments to the DeepIterator constructor inherits this property, > e.g: > > DeepIterator::createVariant() and as a consequence also: > SelectionState::switchLinkToSelection() and > SelectionState::adjustSelection() > > In Iterator::scrollTo() Iterators that are used after being > passed to the DeepIterator constructor. > > In SelectionState::buttonRelease() an iterator that has been passed > to switchLinkToSelection() might be used afterwards as argument to > adjustSelection(). > > I would propose to change the behaviour of the DeepIterator > constructor and always clone its input Iterator. > Better be safe than sorry and the fact that there is already several > bugs related to this shows, that the current behaviour - even if > it's documented - is really dangerous. > > What do you think? I agree with you. This is an API which already has hard-to-find side effects. Set DeepIterator to always clone, and if there's a performance penalty that's worth addressing, we may add a reference-parameter version of the constructor. -- Cheers Jorge.-

July 3, 2008

[patch] use delete[] where necessary

by Johannes.Hofmann＠gmx.de

Hi, attached patch uses delete[] for deleting arrays as required by C++. Cheers, Johannes

July 2, 2008

[patch] fix findtext for single char searches

by Johannes.Hofmann＠gmx.de

Hi, attached patch fixes a segfault when searching for single characters. Cheers, Johannes

July 2, 2008

iterator related bugs

by Johannes.Hofmann＠gmx.de

Hi, while looking for the reason of the rare selection related crashes I found something that seems like a severe bunch of bugs in the iterator code. It might be related to the crash, but I'm not 100% sure yet. There is this innocent comment in front of the DeepIterator constructor in iterator.cc: If you want to continue using \em it, pass it->cloneIterator(). This means, that the DeepIterator constructor eats up the Iterator it get's passed a pointer to! The evil thing is that every method that passes one of it's arguments to the DeepIterator constructor inherits this property, e.g: DeepIterator::createVariant() and as a consequence also: SelectionState::switchLinkToSelection() and SelectionState::adjustSelection() In Iterator::scrollTo() Iterators that are used after being passed to the DeepIterator constructor. In SelectionState::buttonRelease() an iterator that has been passed to switchLinkToSelection() might be used afterwards as argument to adjustSelection(). I would propose to change the behaviour of the DeepIterator constructor and always clone its input Iterator. Better be safe than sorry and the fact that there is already several bugs related to this shows, that the current behaviour - even if it's documented - is really dangerous. What do you think? Cheers, Johannes

July 2, 2008

patch: (any Solarians in the audience?) rm nanosleep solaris workaround

by corvid＠lavabit.com

It seems that there was a nanosleep() in src/IO/dpi.c long ago, but I can't find any nanosleep()s anywhere anymore, so...

July 2, 2008

what's next

by jcid＠dillo.org

On Mon, Jun 30, 2008 at 05:44:40PM +0200, Johannes Hofmann wrote: > Hi, > > for me dillo-fltk is pretty stable, fast, and generally a joy to use. > I still see the following issues: > > * In rare cases the screen contents is not properly redrawn due to > the redraw optimization. I'm looking for a way to reproduce it. > Anyone else seeing this? Not me. I'll pay more attention... > * The cursor is not always updated properly when over a link. This > happens while page is rendered and also when drag-scrolling with > the middle mouse button. > > * The bus error I had posted about is still there and I have seen it > once as a segafault with similar stack trace on a Linux box. I > still don't have a way to reproduce it though. Yeah, It'd be good to know what it is. > Any other problems or missing features? > > Jorge, what do you think about officially releasing what we have in > the near future? > Or do you prefer to wait for the big stuff (like CSS)? I'd like to release before CSS. I'll check the TABs stuff and see if it can be coded/included. Releasing by Aug looks OK to me. -- Cheers Jorge.-

June 30, 2008

Should --enable-ansi be removed?

by jcid＠dillo.org

On Sat, Jun 28, 2008 at 02:18:05AM +0000, corvid wrote: > I tried enabling it out of curiosity, and I see > that the code doesn't come close to compiling with it. > > Since it complains a lot about the various > MSG(...) macros > (warning: anonymous variadic macros were introduced in C99), > I'm guessing that the answer will be yes. Now that dillo needs a C++ compiler to build, I don't know whether this option is useful anymore. Does anybody know better? -- Cheers Jorge.-

June 30, 2008

what's next

by Johannes.Hofmann＠gmx.de

Hi, for me dillo-fltk is pretty stable, fast, and generally a joy to use. I still see the following issues: * In rare cases the screen contents is not properly redrawn due to the redraw optimization. I'm looking for a way to reproduce it. Anyone else seeing this? * The cursor is not always updated properly when over a link. This happens while page is rendered and also when drag-scrolling with the middle mouse button. * The bus error I had posted about is still there and I have seen it once as a segafault with similar stack trace on a Linux box. I still don't have a way to reproduce it though. Any other problems or missing features? Jorge, what do you think about officially releasing what we have in the near future? Or do you prefer to wait for the big stuff (like CSS)? Cheers, Johannes

June 30, 2008

Should --enable-ansi be removed?

by onepoint＠starurchin.org

On Sat, Jun 28, 2008 at 02:18:05AM +0000, corvid wrote: > Since it complains a lot about the various MSG(...) macros (warning: > anonymous variadic macros were introduced in C99), I tried to get -pedantic to work and I could silence those warnings in the C source by specifying -std=gnu99 but I could find no gcc 3.4.x option to do the same for C++ source. Maybe gcc 4.x has one? Regards, Jeremy Henty

June 28, 2008

Should --enable-ansi be removed?

by corvid＠lavabit.com

> I tried enabling it out of curiosity, and I see > that the code doesn't come close to compiling with it. > > Since it complains a lot about the various > MSG(...) macros > (warning: anonymous variadic macros were introduced in C99), > I'm guessing that the answer will be yes. To save any time spent discussing whether warnings with a rarely-used option can be ignored, I should mention that it also gave errors for, e.g., bitvec, apparently because a struct is returned. I can't imagine that we'd want to start changing around such things for the sake of this.

June 28, 2008

Should --enable-ansi be removed?

by corvid＠lavabit.com

I tried enabling it out of curiosity, and I see that the code doesn't come close to compiling with it. Since it complains a lot about the various MSG(...) macros (warning: anonymous variadic macros were introduced in C99), I'm guessing that the answer will be yes.

June 28, 2008

[patch] use prefs.vw_fontname

by jcid＠dillo.org

On Thu, Jun 26, 2008 at 09:54:07PM +0200, Johannes Hofmann wrote: > Hi, > > attached patch uses prefs.vw_fontname instead of hardcoded > "Bitstream Charter" in web.cc. Thereby it avoids opening "Bitstream > Charter" if it is not selected in dillorc. > This saves about 500k in initial startup size with --disable-xft > It hardly saves anything in the xft case. I don't know why. I would > have expected it the other way round.... Committed. -- Cheers Jorge.-

June 27, 2008

[patch] use prefs.vw_fontname

by jcid＠dillo.org

On Thu, Jun 26, 2008 at 09:54:07PM +0200, Johannes Hofmann wrote: > Hi, > > attached patch uses prefs.vw_fontname instead of hardcoded > "Bitstream Charter" in web.cc. Thereby it avoids opening "Bitstream > Charter" if it is not selected in dillorc. > This saves about 500k in initial startup size with --disable-xft > It hardly saves anything in the xft case. I don't know why. I would > have expected it the other way round.... IIRC, long ago Sebastian told me there was something strange with font handling (but at the time we had so many doubts...) -- Cheers Jorge.-

June 27, 2008

[patch] use prefs.vw_fontname

by Johannes.Hofmann＠gmx.de

Hi, attached patch uses prefs.vw_fontname instead of hardcoded "Bitstream Charter" in web.cc. Thereby it avoids opening "Bitstream Charter" if it is not selected in dillorc. This saves about 500k in initial startup size with --disable-xft It hardly saves anything in the xft case. I don't know why. I would have expected it the other way round.... Cheers, Johannes

June 26, 2008

Memory usage

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Mon, Jun 23, 2008 at 05:44:11PM -0400, Jorge Arellano Cid wrote: > On Sun, Jun 22, 2008 at 10:11:30AM -0400, Jorge Arellano Cid wrote: > > ------------------------------------------- > > Huge page with different memory allocators: > > ------------------------------------------- > > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > > 5.4 134912 113740 pts/17 S+ 18:56 0:02 ./dillo-fltk step: 2x > > 5.4 134916 113752 pts/17 S+ 18:57 0:02 ./dillo-fltk step: 2x > > 5.4 134828 113660 pts/17 S+ 18:58 0:02 ./dillo-fltk step: 2x > > > > 5.0 114940 105432 pts/17 S+ 18:53 0:02 ./dillo-fltk step: 1 > > 5.0 111976 105488 pts/17 S+ 18:54 0:03 ./dillo-fltk step: 1 > > 5.0 114872 105416 pts/17 S+ 18:54 0:02 ./dillo-fltk step: 1 > > > > 5.1 117796 106436 pts/17 S+ 18:59 0:02 ./dillo-fltk step: cst > > 5.1 117568 106404 pts/17 S+ 19:00 0:02 ./dillo-fltk step: cst > > 5.1 117820 106460 pts/17 S+ 19:00 0:02 ./dillo-fltk step: cst > > > > > > This data comes from a memory usage reduction by tunning the > > simpleVector memory allocator. The first is the current one, > > which allocates in chunks of 2*numAlloc, the second allocates one > > by one and the third is a custom one I made. > > > > The 1-allocator is the best memory usage reducer but it's > > slower (roughly 20%). The cst-allocator reduces a bit less but is > > almost as fast as the 2x-allocator (2% slower or so). > > > > Memory reduction: > > > > VSZ RSS > > ----------------------------- > > 1-allocator 15% 7.3% > > cst-allocator 13% 6.5% > > ----------------------------- > > After some more study I got to a second cst2-allocator that reduces > almost as much as the 1-allocator but with the same (or better) speed > than the 2x one! > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > > 5.0 114940 105432 pts/17 S+ 18:53 0:02 ./dillo-fltk step: 1 > > 5.0 111976 105488 pts/17 S+ 18:54 0:03 ./dillo-fltk step: 1 > > 5.0 114872 105416 pts/17 S+ 18:54 0:02 ./dillo-fltk step: 1 > > 5.1 113224 105820 pts/17 S+ 13:57 0:02 ./dillo-fltk step: cst2 > 5.0 112948 105740 pts/17 S+ 13:58 0:02 ./dillo-fltk step: cst2 > 5.0 115528 105628 pts/17 S+ 13:59 0:02 ./dillo-fltk step: cst2 > > So now we have: > > ----------------------------- > Memory reduction: > > VSZ RSS > ----------------------------- > 1-allocator 15% 7.3% > cst-allocator 13% 6.5% > cst2-allocator 15% 7.3% > ----------------------------- > > > Committed. I have some concerns regarding the new SimpleVector implementation: * It introduces two arbitrary numbers (100 as a limit to switch to a different bahaviour, and the 1/10 factor) which are optimized for a specific page on a specific platform. The original 2x method feels more general to me even though it may be a bit less memory efficient. * It probabely only works fast, as most malloc libraries use some heuristics to avoid memcpy for every realloc. Depending on this behaviour may create problems on more exotic platforms. * Rather than igoring the initAlloc parameter I would propose to reconsider the places where SimpleVector() is inititalized with initAlloc > 1. There also is an interesting comment about initAlloc in the Textblock constructor. Having said all this, it's not a big issue for me. If CPU usage should really become a problem on some platform, we could easily change the code. It's just 2 or 3 lines after all. Cheers, Johannes

June 26, 2008

Memory usage

by Johannes.Hofmann＠gmx.de

On Mon, Jun 23, 2008 at 05:44:11PM -0400, Jorge Arellano Cid wrote: > On Sun, Jun 22, 2008 at 10:11:30AM -0400, Jorge Arellano Cid wrote: > > ------------------------------------------- > > Huge page with different memory allocators: > > ------------------------------------------- > > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > > 5.4 134912 113740 pts/17 S+ 18:56 0:02 ./dillo-fltk step: 2x > > 5.4 134916 113752 pts/17 S+ 18:57 0:02 ./dillo-fltk step: 2x > > 5.4 134828 113660 pts/17 S+ 18:58 0:02 ./dillo-fltk step: 2x > > > > 5.0 114940 105432 pts/17 S+ 18:53 0:02 ./dillo-fltk step: 1 > > 5.0 111976 105488 pts/17 S+ 18:54 0:03 ./dillo-fltk step: 1 > > 5.0 114872 105416 pts/17 S+ 18:54 0:02 ./dillo-fltk step: 1 > > > > 5.1 117796 106436 pts/17 S+ 18:59 0:02 ./dillo-fltk step: cst > > 5.1 117568 106404 pts/17 S+ 19:00 0:02 ./dillo-fltk step: cst > > 5.1 117820 106460 pts/17 S+ 19:00 0:02 ./dillo-fltk step: cst > > > > > > This data comes from a memory usage reduction by tunning the > > simpleVector memory allocator. The first is the current one, > > which allocates in chunks of 2*numAlloc, the second allocates one > > by one and the third is a custom one I made. > > > > The 1-allocator is the best memory usage reducer but it's > > slower (roughly 20%). The cst-allocator reduces a bit less but is > > almost as fast as the 2x-allocator (2% slower or so). > > > > Memory reduction: > > > > VSZ RSS > > ----------------------------- > > 1-allocator 15% 7.3% > > cst-allocator 13% 6.5% > > ----------------------------- > > After some more study I got to a second cst2-allocator that reduces > almost as much as the 1-allocator but with the same (or better) speed > than the 2x one! > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > > 5.0 114940 105432 pts/17 S+ 18:53 0:02 ./dillo-fltk step: 1 > > 5.0 111976 105488 pts/17 S+ 18:54 0:03 ./dillo-fltk step: 1 > > 5.0 114872 105416 pts/17 S+ 18:54 0:02 ./dillo-fltk step: 1 > > 5.1 113224 105820 pts/17 S+ 13:57 0:02 ./dillo-fltk step: cst2 > 5.0 112948 105740 pts/17 S+ 13:58 0:02 ./dillo-fltk step: cst2 > 5.0 115528 105628 pts/17 S+ 13:59 0:02 ./dillo-fltk step: cst2 > > So now we have: > > ----------------------------- > Memory reduction: > > VSZ RSS > ----------------------------- > 1-allocator 15% 7.3% > cst-allocator 13% 6.5% > cst2-allocator 15% 7.3% > ----------------------------- > > > Committed. Here some results from DragonFly. BTW it found out that by switching off speedstep and thereby locking the CPU to 600MHz I can get more consistent timings. Old SimpleVector: real 0m9.284s user 0m7.921s sys 0m0.336s USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND hofmann 18621 19.5 7.7 141288 119732 p2 SL+ 4:39PM 0:04.01 ./dillo-fltk New SimpleVector from cvs: real 0m10.012s user 0m8.005s sys 0m0.585s USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND hofmann 19344 41.6 7.6 126796 119464 p2 SL+ 4:41PM 0:04.39 ./dillo-fltk So there is a considerable memory reduction but also a noticable higher CPU (especially system) load. Cheers, Johannes

June 24, 2008

Memory usage

by jcid＠dillo.org

On Sun, Jun 22, 2008 at 08:49:17PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > > On Sun, Jun 22, 2008 at 10:11:30AM -0400, Jorge Arellano Cid wrote: > > Hi there, > > > > I've been reviewing memory usage these days, and found some > > weird numbers that I'd like to understand. > > > > Taking the huge mysql page (13MB), I made the following > > memory measures (with ps). Load a bare dillo, load the simple > > directory where the huge page is located, then the huge page, > > then back, then forward, back, forward and back. > > > > I did this for dillo2.19Jun, dillo2.21Jun, dillo-fltk (with > > zone allocators) and dillo1. All in GNU/Linux with image_off. > > > > Here are the numbers: > > > > ----------- > > Memory test > > ----------- > > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > > 0.1 9672 4144 pts/10 S+ 09:37 0:00 ./dillo-fltk.19Jun bare > > 0.2 10376 4756 pts/10 S+ 09:37 0:00 ./dillo-fltk.19Jun dir list > > 6.9 176176 144776 pts/10 S+ 09:37 0:02 ./dillo-fltk.19Jun huge page > > 5.4 123556 113216 pts/10 S+ 09:37 0:02 ./dillo-fltk.19Jun back > > 7.0 176176 146240 pts/10 S+ 09:37 0:05 ./dillo-fltk.19Jun forward > > 5.6 127020 117720 pts/10 S+ 09:37 0:05 ./dillo-fltk.19Jun back > > 7.0 176172 146240 pts/10 S+ 09:37 0:07 ./dillo-fltk.19Jun forward > > 5.6 127016 117716 pts/10 S+ 09:37 0:08 ./dillo-fltk.19Jun back > > > > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > > 0.1 9672 4140 pts/10 S+ 09:26 0:00 ./dillo-fltk.21Jun bare > > 0.2 10376 4760 pts/10 S+ 09:26 0:00 ./dillo-fltk.21Jun dir list > > 5.9 147904 123988 pts/10 S+ 09:31 0:02 ./dillo-fltk.21Jun huge page > > 4.9 111668 101944 pts/10 S+ 09:31 0:02 ./dillo-fltk.21Jun back > > 6.0 147780 124792 pts/10 S+ 09:31 0:05 ./dillo-fltk.21Jun forward > > 5.0 115008 105780 pts/10 S+ 09:31 0:05 ./dillo-fltk.21Jun back > > 6.0 147780 124856 pts/10 S+ 09:31 0:07 ./dillo-fltk.21Jun forward > > 5.1 115008 105844 pts/10 S+ 09:31 0:07 ./dillo-fltk.21Jun back > > > > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > > 0.1 9676 4084 pts/10 S+ 11:16 0:00 ./dillo-fltk bare > > 0.2 10464 4768 pts/10 S+ 11:17 0:00 ./dillo-fltk dir list > > 5.4 136960 112920 pts/10 S+ 11:17 0:04 ./dillo-fltk huge page > > 4.3 100724 90864 pts/10 S+ 11:17 0:04 ./dillo-fltk back > > 5.4 136952 113756 pts/10 S+ 11:17 0:09 ./dillo-fltk forward > > 4.5 104180 94744 pts/10 S+ 11:17 0:09 ./dillo-fltk back > > 5.4 136888 113776 pts/10 S+ 11:17 0:13 ./dillo-fltk forward > > 4.5 104116 94764 pts/10 S+ 11:17 0:14 ./dillo-fltk back > > > > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > > 0.1 8408 3524 pts/10 S+ 10:59 0:00 ./dillo1 bare > > 0.1 24788 3564 pts/10 S+ 11:01 0:00 ./dillo1 dir list > > 8.7 226996 182220 pts/10 S+ 11:01 0:07 ./dillo1 huge page > > 6.8 165880 141792 pts/10 S+ 11:01 0:09 ./dillo1 back > > 8.8 226952 184176 pts/10 S+ 11:01 0:17 ./dillo1 forward > > 6.9 166264 144024 pts/10 S+ 11:01 0:18 ./dillo1 back > > 8.8 226968 184216 pts/10 S+ 11:01 0:26 ./dillo1 forward > > 6.9 166264 144060 pts/10 S+ 11:01 0:27 ./dillo1 back > > > > > > Besides showing clearly a sane memory usage reduction pattern, > > there's a strange fact I don't understand. Once back from the > > huge page, I'd expect memory usage to drop to what it was before > > plus the 13MB of cached data, plus some KB of overhead, BUT the > > RSS keeps near 90MB. > > > > This happens with dillo1 too. > > > > My thoughts: > > > > * If this memory is not freed, it'd be great to find the huge > > leak. > > * If it's freed but not returned to the OS., dillo would > > consume as much memory as the biggest page it has loaded. > > Clearly not a desirable situation. > > * It may be that the O.S. knows it can claim back this memory > > when necessary but prefers to keep it assigned to the > > same process until it finds better use for it. > > I think this is related to the malloc implementation in Linux/glibc. > Here on DragonFly I get: > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > hofmann 3331 0.0 0.3 6732 4436 p3 IL+ 8:37PM 0:00.14 ./dillo-fltk dir list > hofmann 3331 26.9 7.6 140116 118580 p3 SL+ 8:37PM 0:04.13 ./dillo-fltk huge page > hofmann 3331 10.3 1.2 25488 19064 p3 SL+ 8:37PM 0:05.38 ./dillo-fltk back > hofmann 3331 79.2 7.6 140112 118584 p3 SL+ 8:37PM 0:09.90 ./dillo-fltk forward > hofmann 3331 11.1 1.3 26252 19840 p3 SL+ 8:37PM 0:11.29 ./dillo-fltk back > hofmann 3331 91.1 7.6 140548 119232 p3 SL+ 8:37PM 0:15.67 ./dillo-fltk forward > hofmann 3331 27.8 1.3 26816 20392 p3 SL+ 8:37PM 0:16.98 ./dillo-fltk back > > Which is not perfect, but reasonable. > I think DragonFly has changed the malloc implementation some time > ago. If I remember correctly there was a more Linux-like behaviour > before. Well, this explains a lof of things, including why in your system there's a speed improvement when leaving the huge page. There're still 6MB VSZ (2MB RSS) I can't explain considering the page in the cache is 13MB. I've seen leaks even with plain text, but this is not huge. Thanks for the info! -- Cheers Jorge.-

June 24, 2008

Memory usage

by jcid＠dillo.org

On Sun, Jun 22, 2008 at 10:11:30AM -0400, Jorge Arellano Cid wrote: > ------------------------------------------- > Huge page with different memory allocators: > ------------------------------------------- > > %MEM VSZ RSS TTY STAT START TIME COMMAND > 5.4 134912 113740 pts/17 S+ 18:56 0:02 ./dillo-fltk step: 2x > 5.4 134916 113752 pts/17 S+ 18:57 0:02 ./dillo-fltk step: 2x > 5.4 134828 113660 pts/17 S+ 18:58 0:02 ./dillo-fltk step: 2x > > 5.0 114940 105432 pts/17 S+ 18:53 0:02 ./dillo-fltk step: 1 > 5.0 111976 105488 pts/17 S+ 18:54 0:03 ./dillo-fltk step: 1 > 5.0 114872 105416 pts/17 S+ 18:54 0:02 ./dillo-fltk step: 1 > > 5.1 117796 106436 pts/17 S+ 18:59 0:02 ./dillo-fltk step: cst > 5.1 117568 106404 pts/17 S+ 19:00 0:02 ./dillo-fltk step: cst > 5.1 117820 106460 pts/17 S+ 19:00 0:02 ./dillo-fltk step: cst > > > This data comes from a memory usage reduction by tunning the > simpleVector memory allocator. The first is the current one, > which allocates in chunks of 2*numAlloc, the second allocates one > by one and the third is a custom one I made. > > The 1-allocator is the best memory usage reducer but it's > slower (roughly 20%). The cst-allocator reduces a bit less but is > almost as fast as the 2x-allocator (2% slower or so). > > Memory reduction: > > VSZ RSS > ----------------------------- > 1-allocator 15% 7.3% > cst-allocator 13% 6.5% > ----------------------------- After some more study I got to a second cst2-allocator that reduces almost as much as the 1-allocator but with the same (or better) speed than the 2x one! > %MEM VSZ RSS TTY STAT START TIME COMMAND > 5.0 114940 105432 pts/17 S+ 18:53 0:02 ./dillo-fltk step: 1 > 5.0 111976 105488 pts/17 S+ 18:54 0:03 ./dillo-fltk step: 1 > 5.0 114872 105416 pts/17 S+ 18:54 0:02 ./dillo-fltk step: 1 5.1 113224 105820 pts/17 S+ 13:57 0:02 ./dillo-fltk step: cst2 5.0 112948 105740 pts/17 S+ 13:58 0:02 ./dillo-fltk step: cst2 5.0 115528 105628 pts/17 S+ 13:59 0:02 ./dillo-fltk step: cst2 So now we have: ----------------------------- Memory reduction: VSZ RSS ----------------------------- 1-allocator 15% 7.3% cst-allocator 13% 6.5% cst2-allocator 15% 7.3% ----------------------------- Committed. -- Cheers Jorge.-

June 24, 2008

[patch] Region is no Shape

by jcid＠dillo.org

On Mon, Jun 23, 2008 at 07:41:06PM +0200, Johannes Hofmann wrote: > Hi, > > attached patch cleans up Region. It no longer derives from Shape. > Region has grown pretty specialize for handling redraws. Also it was > never used as Shape object anyway. Committed. -- Cheers Jorge.-

June 23, 2008

[patch] cleanup ZoneAllocator

by jcid＠dillo.org

On Mon, Jun 23, 2008 at 07:38:42PM +0200, Johannes Hofmann wrote: > Hi, > > here comes me ZoneAllocator cleanup again. This time without the > questionable strlen() stuff. Committed. -- Cheers Jorge.-

June 23, 2008

form.cc: more refactoring

by jcid＠dillo.org

On Mon, Jun 23, 2008 at 12:58:41AM +0100, Jeremy Henty wrote: > On Fri, Jun 20, 2008 at 02:37:22PM -0400, Jorge Arellano Cid wrote: > > On Thu, Jun 19, 2008 at 08:48:48PM +0100, Jeremy Henty wrote: > > > On Wed, Jun 18, 2008 at 08:35:57AM -0400, Jorge Arellano Cid wrote: > > > > > > > Committed, except 00 and 05. > > > > > > > > 00: The stash buffer may hold a script, in that case > > > > parse_stash is not as clear as parse_entities. > > > > > > Would a better name make the change acceptable? For instance, > > > Html_parse_stash_entries() ? > > > > Html_parse_stash_entities() ? > > > > Why is it better than the traditional a_Html_parse_entities()? > > Sorry, I wasn't very clear. I read you as saying that the new > function a_Html_parse_stash() was not very well named, and I meant to > suggest a_Html_parse_stash_entities() as an improvement. If you were > saying that the refactoring itself is confusing then I misread you. I find the generic a_Html_parse_entities() OK. -- Cheers Jorge.-

June 23, 2008

[patch] Region is no Shape

by Johannes.Hofmann＠gmx.de

Hi, attached patch cleans up Region. It no longer derives from Shape. Region has grown pretty specialize for handling redraws. Also it was never used as Shape object anyway. Cheers, Johannes

June 23, 2008

[patch] cleanup ZoneAllocator

by Johannes.Hofmann＠gmx.de

Hi, here comes me ZoneAllocator cleanup again. This time without the questionable strlen() stuff. Cheers, Johannes

June 23, 2008

patch: Re: [Dillo-dev] back to that SELECT segfault

by corvid＠lavabit.com

Jorge wrote: > On Mon, Jun 23, 2008 at 05:05:29AM +0000, corvid wrote: > > In SELECT, if standard_widget_colors is set, color and backgroundColor > > are set to NULL. This tells FltkResource::setWidgetStyle() to leave > > the colors on the widget alone. > > > > If an inline element inside a SELECT calls > > style->color->getColor() or style->backgroundColor->getColor(), > > we get that crash. > > > > This currently means FONT and IMG. > > OBJECT and A would as well if that a_Color_vc code were uncommented. > > > > options: > > - four IN_SELECT tests. > > - letting Html_stack_cleanup_at_open() be called for inline elements > > in order to close the SELECT or something if IN_SELECT and the new tag > > isn't OPTION or OPTGROUP. > > - generating our own standard widget colors to put into color and > > backgroundColor. > > > > I don't like the first one because someone innocently adding a > > getColor somewhere in the future will never know about this danger. > > (a good example would be adding the a_Color_vc to open_frame()) > > Without a deep understanding of the code involved, I'd > prefer the third option (standard widget colors) as it looks > more general and simple as a solution. All right.

June 23, 2008

back to that SELECT segfault

by onepoint＠starurchin.org

On Mon, Jun 23, 2008 at 10:01:43AM +0000, corvid wrote: > Jeremy wrote: > > On Mon, Jun 23, 2008 at 05:05:29AM +0000, corvid wrote: > > > > > In SELECT, if standard_widget_colors is set, color and > > > backgroundColor are set to NULL. ... > > > > This is done for most input types in form.cc, not just SELECT, see: > > * Html_tag_open_input() > > * Html_tag_open_isindex() > > * Html_tag_open_select() > > > > However it is not done in: > > * Html_tag_open_button() > > * Html_input_image() > > The first three show fltk widgets. Hmm, whereas the other two create a ComplexButtonResource that does not. > > Is the potential crash only an issue for SELECT inputs? If so, > > why? > > INPUT and ISINDEX don't have close tags, so other tags can't be > sneaked inside them. Thanks for that. This is the bit of form.cc that I understand least which is why I have all these questions. I want to refactor the various code paths that lead to AddInput() but every time I look I see more ways in which they do things differently. The paths that call Html_tag_open_button() and Html_input_image() are particularly tricky and refactoring them correctly depends on understanding the DilloHtml stack, widget styles and layouts etc. Regards, Jeremy Henty

June 23, 2008

back to that SELECT segfault

by jcid＠dillo.org

On Mon, Jun 23, 2008 at 05:05:29AM +0000, corvid wrote: > In SELECT, if standard_widget_colors is set, color and backgroundColor > are set to NULL. This tells FltkResource::setWidgetStyle() to leave > the colors on the widget alone. > > If an inline element inside a SELECT calls > style->color->getColor() or style->backgroundColor->getColor(), > we get that crash. > > This currently means FONT and IMG. > OBJECT and A would as well if that a_Color_vc code were uncommented. > > options: > - four IN_SELECT tests. > - letting Html_stack_cleanup_at_open() be called for inline elements > in order to close the SELECT or something if IN_SELECT and the new tag > isn't OPTION or OPTGROUP. > - generating our own standard widget colors to put into color and > backgroundColor. > > I don't like the first one because someone innocently adding a > getColor somewhere in the future will never know about this danger. > (a good example would be adding the a_Color_vc to open_frame()) Without a deep understanding of the code involved, I'd prefer the third option (standard widget colors) as it looks more general and simple as a solution. -- Cheers Jorge.-

June 23, 2008

back to that SELECT segfault

by corvid＠lavabit.com

Jeremy wrote: > On Mon, Jun 23, 2008 at 05:05:29AM +0000, corvid wrote: > > > In SELECT, if standard_widget_colors is set, color and > > backgroundColor are set to NULL. This tells > > FltkResource::setWidgetStyle() to leave the colors on the widget > > alone. > > This is done for most input types in form.cc, not just SELECT, see: > * Html_tag_open_input() > * Html_tag_open_isindex() > * Html_tag_open_select() > > However it is not done in: > * Html_tag_open_button() > * Html_input_image() The first three show fltk widgets. > Is the potential crash only an issue for SELECT inputs? If so, why? INPUT and ISINDEX don't have close tags, so other tags can't be sneaked inside them. > > If an inline element inside a SELECT calls style->color->getColor() > > or style->backgroundColor->getColor(), we get that crash. > > There's dw::core::Widget::getBgColor() , which chains up the widget > hierarchy looking for a non-NULL background color. Perhaps we should > be calling that? However there is no equivalent (that I can see) for > foreground colors. Perhaps there should be? I guess the getColor()s could go in something that goes up the DilloHtmlState stack looking for non-NULL...

June 23, 2008

back to that SELECT segfault

by onepoint＠starurchin.org

On Mon, Jun 23, 2008 at 05:05:29AM +0000, corvid wrote: > In SELECT, if standard_widget_colors is set, color and > backgroundColor are set to NULL. This tells > FltkResource::setWidgetStyle() to leave the colors on the widget > alone. This is done for most input types in form.cc, not just SELECT, see: * Html_tag_open_input() * Html_tag_open_isindex() * Html_tag_open_select() However it is not done in: * Html_tag_open_button() * Html_input_image() Is the potential crash only an issue for SELECT inputs? If so, why? > If an inline element inside a SELECT calls style->color->getColor() > or style->backgroundColor->getColor(), we get that crash. There's dw::core::Widget::getBgColor() , which chains up the widget hierarchy looking for a non-NULL background color. Perhaps we should be calling that? However there is no equivalent (that I can see) for foreground colors. Perhaps there should be? Regards, Jeremy Henty

June 23, 2008

back to that SELECT segfault

by corvid＠lavabit.com

In SELECT, if standard_widget_colors is set, color and backgroundColor are set to NULL. This tells FltkResource::setWidgetStyle() to leave the colors on the widget alone. If an inline element inside a SELECT calls style->color->getColor() or style->backgroundColor->getColor(), we get that crash. This currently means FONT and IMG. OBJECT and A would as well if that a_Color_vc code were uncommented. options: - four IN_SELECT tests. - letting Html_stack_cleanup_at_open() be called for inline elements in order to close the SELECT or something if IN_SELECT and the new tag isn't OPTION or OPTGROUP. - generating our own standard widget colors to put into color and backgroundColor. I don't like the first one because someone innocently adding a getColor somewhere in the future will never know about this danger. (a good example would be adding the a_Color_vc to open_frame())

June 23, 2008

form.cc: more refactoring

by onepoint＠starurchin.org

On Fri, Jun 20, 2008 at 02:37:22PM -0400, Jorge Arellano Cid wrote: > On Thu, Jun 19, 2008 at 08:48:48PM +0100, Jeremy Henty wrote: > > On Wed, Jun 18, 2008 at 08:35:57AM -0400, Jorge Arellano Cid wrote: > > > > > Committed, except 00 and 05. > > > > > > 00: The stash buffer may hold a script, in that case > > > parse_stash is not as clear as parse_entities. > > > > Would a better name make the change acceptable? For instance, > > Html_parse_stash_entries() ? > > Html_parse_stash_entities() ? > > Why is it better than the traditional a_Html_parse_entities()? Sorry, I wasn't very clear. I read you as saying that the new function a_Html_parse_stash() was not very well named, and I meant to suggest a_Html_parse_stash_entities() as an improvement. If you were saying that the refactoring itself is confusing then I misread you. Regards, Jeremy Henty

June 23, 2008

Memory usage

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Sun, Jun 22, 2008 at 10:11:30AM -0400, Jorge Arellano Cid wrote: > Hi there, > > I've been reviewing memory usage these days, and found some > weird numbers that I'd like to understand. > > Taking the huge mysql page (13MB), I made the following > memory measures (with ps). Load a bare dillo, load the simple > directory where the huge page is located, then the huge page, > then back, then forward, back, forward and back. > > I did this for dillo2.19Jun, dillo2.21Jun, dillo-fltk (with > zone allocators) and dillo1. All in GNU/Linux with image_off. > > Here are the numbers: > > ----------- > Memory test > ----------- > > %MEM VSZ RSS TTY STAT START TIME COMMAND > 0.1 9672 4144 pts/10 S+ 09:37 0:00 ./dillo-fltk.19Jun bare > 0.2 10376 4756 pts/10 S+ 09:37 0:00 ./dillo-fltk.19Jun dir list > 6.9 176176 144776 pts/10 S+ 09:37 0:02 ./dillo-fltk.19Jun huge page > 5.4 123556 113216 pts/10 S+ 09:37 0:02 ./dillo-fltk.19Jun back > 7.0 176176 146240 pts/10 S+ 09:37 0:05 ./dillo-fltk.19Jun forward > 5.6 127020 117720 pts/10 S+ 09:37 0:05 ./dillo-fltk.19Jun back > 7.0 176172 146240 pts/10 S+ 09:37 0:07 ./dillo-fltk.19Jun forward > 5.6 127016 117716 pts/10 S+ 09:37 0:08 ./dillo-fltk.19Jun back > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > 0.1 9672 4140 pts/10 S+ 09:26 0:00 ./dillo-fltk.21Jun bare > 0.2 10376 4760 pts/10 S+ 09:26 0:00 ./dillo-fltk.21Jun dir list > 5.9 147904 123988 pts/10 S+ 09:31 0:02 ./dillo-fltk.21Jun huge page > 4.9 111668 101944 pts/10 S+ 09:31 0:02 ./dillo-fltk.21Jun back > 6.0 147780 124792 pts/10 S+ 09:31 0:05 ./dillo-fltk.21Jun forward > 5.0 115008 105780 pts/10 S+ 09:31 0:05 ./dillo-fltk.21Jun back > 6.0 147780 124856 pts/10 S+ 09:31 0:07 ./dillo-fltk.21Jun forward > 5.1 115008 105844 pts/10 S+ 09:31 0:07 ./dillo-fltk.21Jun back > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > 0.1 9676 4084 pts/10 S+ 11:16 0:00 ./dillo-fltk bare > 0.2 10464 4768 pts/10 S+ 11:17 0:00 ./dillo-fltk dir list > 5.4 136960 112920 pts/10 S+ 11:17 0:04 ./dillo-fltk huge page > 4.3 100724 90864 pts/10 S+ 11:17 0:04 ./dillo-fltk back > 5.4 136952 113756 pts/10 S+ 11:17 0:09 ./dillo-fltk forward > 4.5 104180 94744 pts/10 S+ 11:17 0:09 ./dillo-fltk back > 5.4 136888 113776 pts/10 S+ 11:17 0:13 ./dillo-fltk forward > 4.5 104116 94764 pts/10 S+ 11:17 0:14 ./dillo-fltk back > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > 0.1 8408 3524 pts/10 S+ 10:59 0:00 ./dillo1 bare > 0.1 24788 3564 pts/10 S+ 11:01 0:00 ./dillo1 dir list > 8.7 226996 182220 pts/10 S+ 11:01 0:07 ./dillo1 huge page > 6.8 165880 141792 pts/10 S+ 11:01 0:09 ./dillo1 back > 8.8 226952 184176 pts/10 S+ 11:01 0:17 ./dillo1 forward > 6.9 166264 144024 pts/10 S+ 11:01 0:18 ./dillo1 back > 8.8 226968 184216 pts/10 S+ 11:01 0:26 ./dillo1 forward > 6.9 166264 144060 pts/10 S+ 11:01 0:27 ./dillo1 back > > > Besides showing clearly a sane memory usage reduction pattern, > there's a strange fact I don't understand. Once back from the > huge page, I'd expect memory usage to drop to what it was before > plus the 13MB of cached data, plus some KB of overhead, BUT the > RSS keeps near 90MB. > > This happens with dillo1 too. > > My thoughts: > > * If this memory is not freed, it'd be great to find the huge > leak. > * If it's freed but not returned to the OS., dillo would > consume as much memory as the biggest page it has loaded. > Clearly not a desirable situation. > * It may be that the O.S. knows it can claim back this memory > when necessary but prefers to keep it assigned to the > same process until it finds better use for it. I think this is related to the malloc implementation in Linux/glibc. Here on DragonFly I get: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND hofmann 3331 0.0 0.3 6732 4436 p3 IL+ 8:37PM 0:00.14 ./dillo-fltk dir list hofmann 3331 26.9 7.6 140116 118580 p3 SL+ 8:37PM 0:04.13 ./dillo-fltk huge page hofmann 3331 10.3 1.2 25488 19064 p3 SL+ 8:37PM 0:05.38 ./dillo-fltk back hofmann 3331 79.2 7.6 140112 118584 p3 SL+ 8:37PM 0:09.90 ./dillo-fltk forward hofmann 3331 11.1 1.3 26252 19840 p3 SL+ 8:37PM 0:11.29 ./dillo-fltk back hofmann 3331 91.1 7.6 140548 119232 p3 SL+ 8:37PM 0:15.67 ./dillo-fltk forward hofmann 3331 27.8 1.3 26816 20392 p3 SL+ 8:37PM 0:16.98 ./dillo-fltk back Which is not perfect, but reasonable. I think DragonFly has changed the malloc implementation some time ago. If I remember correctly there was a more Linux-like behaviour before. Cheers, Johannes > > > > ------------------------------------------- > Huge page with different memory allocators: > ------------------------------------------- > > %MEM VSZ RSS TTY STAT START TIME COMMAND > 5.4 134912 113740 pts/17 S+ 18:56 0:02 ./dillo-fltk step: 2x > 5.4 134916 113752 pts/17 S+ 18:57 0:02 ./dillo-fltk step: 2x > 5.4 134828 113660 pts/17 S+ 18:58 0:02 ./dillo-fltk step: 2x > > 5.0 114940 105432 pts/17 S+ 18:53 0:02 ./dillo-fltk step: 1 > 5.0 111976 105488 pts/17 S+ 18:54 0:03 ./dillo-fltk step: 1 > 5.0 114872 105416 pts/17 S+ 18:54 0:02 ./dillo-fltk step: 1 > > 5.1 117796 106436 pts/17 S+ 18:59 0:02 ./dillo-fltk step: cst > 5.1 117568 106404 pts/17 S+ 19:00 0:02 ./dillo-fltk step: cst > 5.1 117820 106460 pts/17 S+ 19:00 0:02 ./dillo-fltk step: cst > > > This data comes from a memory usage reduction by tunning the > simpleVector memory allocator. The first is the current one, > which allocates in chunks of 2*numAlloc, the second allocates one > by one and the third is a custom one I made. > > The 1-allocator is the best memory usage reducer but it's > slower (roughly 20%). The cst-allocator reduces a bit less but is > almost as fast as the 2x-allocator (2% slower or so). > > Memory reduction: > > VSZ RSS > ----------------------------- > 1-allocator 15% 7.3% > cst-allocator 13% 6.5% > ----------------------------- > > Well, compared with the 1000% "leak" above... :-) > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

June 22, 2008

Memory usage

by jcid＠dillo.org

Hi there, I've been reviewing memory usage these days, and found some weird numbers that I'd like to understand. Taking the huge mysql page (13MB), I made the following memory measures (with ps). Load a bare dillo, load the simple directory where the huge page is located, then the huge page, then back, then forward, back, forward and back. I did this for dillo2.19Jun, dillo2.21Jun, dillo-fltk (with zone allocators) and dillo1. All in GNU/Linux with image_off. Here are the numbers: ----------- Memory test ----------- %MEM VSZ RSS TTY STAT START TIME COMMAND 0.1 9672 4144 pts/10 S+ 09:37 0:00 ./dillo-fltk.19Jun bare 0.2 10376 4756 pts/10 S+ 09:37 0:00 ./dillo-fltk.19Jun dir list 6.9 176176 144776 pts/10 S+ 09:37 0:02 ./dillo-fltk.19Jun huge page 5.4 123556 113216 pts/10 S+ 09:37 0:02 ./dillo-fltk.19Jun back 7.0 176176 146240 pts/10 S+ 09:37 0:05 ./dillo-fltk.19Jun forward 5.6 127020 117720 pts/10 S+ 09:37 0:05 ./dillo-fltk.19Jun back 7.0 176172 146240 pts/10 S+ 09:37 0:07 ./dillo-fltk.19Jun forward 5.6 127016 117716 pts/10 S+ 09:37 0:08 ./dillo-fltk.19Jun back %MEM VSZ RSS TTY STAT START TIME COMMAND 0.1 9672 4140 pts/10 S+ 09:26 0:00 ./dillo-fltk.21Jun bare 0.2 10376 4760 pts/10 S+ 09:26 0:00 ./dillo-fltk.21Jun dir list 5.9 147904 123988 pts/10 S+ 09:31 0:02 ./dillo-fltk.21Jun huge page 4.9 111668 101944 pts/10 S+ 09:31 0:02 ./dillo-fltk.21Jun back 6.0 147780 124792 pts/10 S+ 09:31 0:05 ./dillo-fltk.21Jun forward 5.0 115008 105780 pts/10 S+ 09:31 0:05 ./dillo-fltk.21Jun back 6.0 147780 124856 pts/10 S+ 09:31 0:07 ./dillo-fltk.21Jun forward 5.1 115008 105844 pts/10 S+ 09:31 0:07 ./dillo-fltk.21Jun back %MEM VSZ RSS TTY STAT START TIME COMMAND 0.1 9676 4084 pts/10 S+ 11:16 0:00 ./dillo-fltk bare 0.2 10464 4768 pts/10 S+ 11:17 0:00 ./dillo-fltk dir list 5.4 136960 112920 pts/10 S+ 11:17 0:04 ./dillo-fltk huge page 4.3 100724 90864 pts/10 S+ 11:17 0:04 ./dillo-fltk back 5.4 136952 113756 pts/10 S+ 11:17 0:09 ./dillo-fltk forward 4.5 104180 94744 pts/10 S+ 11:17 0:09 ./dillo-fltk back 5.4 136888 113776 pts/10 S+ 11:17 0:13 ./dillo-fltk forward 4.5 104116 94764 pts/10 S+ 11:17 0:14 ./dillo-fltk back %MEM VSZ RSS TTY STAT START TIME COMMAND 0.1 8408 3524 pts/10 S+ 10:59 0:00 ./dillo1 bare 0.1 24788 3564 pts/10 S+ 11:01 0:00 ./dillo1 dir list 8.7 226996 182220 pts/10 S+ 11:01 0:07 ./dillo1 huge page 6.8 165880 141792 pts/10 S+ 11:01 0:09 ./dillo1 back 8.8 226952 184176 pts/10 S+ 11:01 0:17 ./dillo1 forward 6.9 166264 144024 pts/10 S+ 11:01 0:18 ./dillo1 back 8.8 226968 184216 pts/10 S+ 11:01 0:26 ./dillo1 forward 6.9 166264 144060 pts/10 S+ 11:01 0:27 ./dillo1 back Besides showing clearly a sane memory usage reduction pattern, there's a strange fact I don't understand. Once back from the huge page, I'd expect memory usage to drop to what it was before plus the 13MB of cached data, plus some KB of overhead, BUT the RSS keeps near 90MB. This happens with dillo1 too. My thoughts: * If this memory is not freed, it'd be great to find the huge leak. * If it's freed but not returned to the OS., dillo would consume as much memory as the biggest page it has loaded. Clearly not a desirable situation. * It may be that the O.S. knows it can claim back this memory when necessary but prefers to keep it assigned to the same process until it finds better use for it. ------------------------------------------- Huge page with different memory allocators: ------------------------------------------- %MEM VSZ RSS TTY STAT START TIME COMMAND 5.4 134912 113740 pts/17 S+ 18:56 0:02 ./dillo-fltk step: 2x 5.4 134916 113752 pts/17 S+ 18:57 0:02 ./dillo-fltk step: 2x 5.4 134828 113660 pts/17 S+ 18:58 0:02 ./dillo-fltk step: 2x 5.0 114940 105432 pts/17 S+ 18:53 0:02 ./dillo-fltk step: 1 5.0 111976 105488 pts/17 S+ 18:54 0:03 ./dillo-fltk step: 1 5.0 114872 105416 pts/17 S+ 18:54 0:02 ./dillo-fltk step: 1 5.1 117796 106436 pts/17 S+ 18:59 0:02 ./dillo-fltk step: cst 5.1 117568 106404 pts/17 S+ 19:00 0:02 ./dillo-fltk step: cst 5.1 117820 106460 pts/17 S+ 19:00 0:02 ./dillo-fltk step: cst This data comes from a memory usage reduction by tunning the simpleVector memory allocator. The first is the current one, which allocates in chunks of 2*numAlloc, the second allocates one by one and the third is a custom one I made. The 1-allocator is the best memory usage reducer but it's slower (roughly 20%). The cst-allocator reduces a bit less but is almost as fast as the 2x-allocator (2% slower or so). Memory reduction: VSZ RSS ----------------------------- 1-allocator 15% 7.3% cst-allocator 13% 6.5% ----------------------------- Well, compared with the 1000% "leak" above... :-) -- Cheers Jorge.-

June 22, 2008

Textblock::addText()

by jcid＠dillo.org

On Sat, Jun 21, 2008 at 11:12:34PM +0200, Johannes Hofmann wrote: > On Sat, Jun 21, 2008 at 04:58:50PM -0400, Jorge Arellano Cid wrote: > > On Sat, Jun 21, 2008 at 10:36:52PM +0200, Johannes Hofmann wrote: > > > 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 get consistent timing with uicmd.cc:647 set to 1. > > But that only works with images enabled, right? Then all timings are > dominated by image decoding. Without images I get timings around 3s > with images it's about 16s. > But anyway, I agree that there is not much gain in avoiding that > strlen call. So let's just forget about that for now. If we can find > a test case where it really helps, we can come back to it. Sorry, I just committed a halt that works both with/without images. (same line). I'm investigating on memory usage, and have further reduced it, but what I'm about to post for discussion is really weird. Stay tuned... -- Cheers Jorge.-

June 22, 2008

Textblock::addText()

by Johannes.Hofmann＠gmx.de

On Sat, Jun 21, 2008 at 04:58:50PM -0400, Jorge Arellano Cid wrote: > On Sat, Jun 21, 2008 at 10:36:52PM +0200, Johannes Hofmann wrote: > > 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 get consistent timing with uicmd.cc:647 set to 1. But that only works with images enabled, right? Then all timings are dominated by image decoding. Without images I get timings around 3s with images it's about 16s. But anyway, I agree that there is not much gain in avoiding that strlen call. So let's just forget about that for now. If we can find a test case where it really helps, we can come back to it. Cheers, Johannes

June 21, 2008

Textblock::addText()

by jcid＠dillo.org

On Sat, Jun 21, 2008 at 10:36:52PM +0200, Johannes Hofmann wrote: > 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 get consistent timing with uicmd.cc:647 set to 1. -- Cheers Jorge.-

June 21, 2008

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

Textblock::addText()

by Johannes.Hofmann＠gmx.de

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. Cheers, Johannes

June 20, 2008

[patch] move highlighting data into Textblock

by jcid＠dillo.org

On Fri, Jun 20, 2008 at 04:26:39PM +0200, Johannes Hofmann wrote: > Hi, > > attached patch fixes the issue here. I had just recently switched > the code from using hlStart[layer].index < 0 to > hlStart[layer].index > hlEnd[layer].index to indicate that nothing > is highlighted. > It turned out that I had forgotten to adapt some parts. > In addition this patch cleans up some rough edges. Committed. -- Cheers Jorge.-

June 20, 2008

form.cc: more refactoring

by jcid＠dillo.org

On Thu, Jun 19, 2008 at 08:48:48PM +0100, Jeremy Henty wrote: > On Wed, Jun 18, 2008 at 08:35:57AM -0400, Jorge Arellano Cid wrote: > > > Committed, except 00 and 05. > > > > 00: The stash buffer may hold a script, in that case parse_stash is not > > as clear as parse_entities. > > Would a better name make the change acceptable? For instance, > Html_parse_stash_entries() ? Html_parse_stash_entities() ? Why is it better than the traditional a_Html_parse_entities()? > > > 05: gives compilation errors: > > [...] > > form.cc: In function 'void Html_option_finish(DilloHtml*)': > > form.cc:184: error: 'lout::misc::SimpleVector<DilloHtmlOption*>* > > DilloHtmlSelect::options' is private > > form.cc:1918: error: within this context > > form.cc:184: error: 'lout::misc::SimpleVector<DilloHtmlOption*>* > > DilloHtmlSelect::options' is private > > form.cc:1918: error: within this context > > That's because not committing 00 breaks one of the chunks in 04 so you > still have an explicit ->inputs which should have been replaced by a > call to getCurrentOption() . I'm appending the missing chunk of 04 > and resubmitting 05 . Committed. -- Cheers Jorge.-

June 20, 2008

Textblock::addText()

by jcid＠dillo.org

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. -- Cheers Jorge.-

June 20, 2008