- Dillo-dev - lists.mailman3.com

patch: free parse data

by corvid＠lavabit.com

Johannes had suggested freeing Local_Buf when parsing was completed...

May 23, 2008

memory statistics

by corvid＠lavabit.com

Jorge wrote: > It'd be great if we can have gprof profiling working on dillo > again. Then use it to see what is the real impact of some > optimizations. I remember Johannes writing that gprof was still giving strange results after he enabled it, but a good start would be to add a line for CXXFLAGS to: if test "x$enable_gprof" = "xyes" ; then CFLAGS="$CFLAGS -pg" fi

May 23, 2008

memory statistics

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Thu, May 22, 2008 at 05:23:04PM -0400, Jorge Arellano Cid wrote: > Hi Johannes, > > On Thu, May 22, 2008 at 12:21:51PM +0200, Johannes Hofmann wrote: > > Hi, > > > > to see which part of dillo consumes which amount of memory, I hacked > > together a version of dlib.c that counts memory that was allocated via > > dMalloc(). A malloc_tag allows to assign the mallocs to specific > > parts in the code. In the patch below I use malloc_tag = 1 for cache > > stuff, malloc_tag = 2 for text strings that are passed dw2 and > > malloc_tag = 0 for everything else. > > It's fun to see how memory get's allocated and free'd while loading. > > Here is the output once the huge mysql manual page is loaded: > > > > ====> malloc size 5185114 26967623 6602392 0 > > > > So that's 6M for text strings, 26M cache and 5M other. > > Of course there is also all the dw2 stuff that is not taken into > > account here. > > Yes, and dw2 stuff should be the main part... Yes, it probabely is, but I wanted to understand what parts use how much memory. One thing I've seen is that Local_Buf in html.cc keeps a copy of the page until it's deleted. Do you think we can free Local_Buf in closeParser() already? It works fine in my test. Another thing is the way new incoming html is handled in DilloHtml::write(). It' get's decoded in a new string and is then copied to the end of Local_Buf. Maybe we could avoid the copy by letting the decoder write it to the right place? Other than that the memory usage (dlib based) seems reasonable to me. > > > BTW, textblock delete's the text strings that are allocated using > > malloc(). That's not allowed and might cause unexpected > > behaviour on some platforms. > > This is clearly a bug. > > A long time ago I thought of dw2 using dlib. Now dw2 is mainly > using its own resources. The simple solution would be to let > addText to allocate and delete the string. Another way is to > study whether is worth to convert dw2 to dlib. The easiest would be to use just use free() in the Textblock destructor but it would be cleaner to free the space where it was allocated. > > It'd be great if we can have gprof profiling working on dillo > again. Then use it to see what is the real impact of some > optimizations. > > A long long time ago (in dillo1), I used to heavily optimize > functions to avoid extra strdups. It ended making the code a lot > more complex and without any noticeable gain. After that we > switched to the simple paradigm of having each function free what > it allocated. Yes, that's true. Some time ago I noticed the huge amount of malloc() and free() that happen while loading a page and I wrote an allocator that get's a large chunk via malloc and then hands out pieces for use in addText(). In the end all text could be free()'d with one call to free. But there was not much of a gain! The standard malloc routines seem to be quite optimized these days :-) > > Can you give a hand at enabling profiling again? I have it working for some time again. My problem was just DragonFly specific and I now have a workaround. Apart from that I compile dw2 and dillo2 with --enable-gprof and fltk2 with --disable-xft. Finally I manually link dillo with the -static and -pg options and the -lXau -lXdmcp libraries added. At http://www.ecademix.com/JohannesHofmann/tmp/refman.prof is a grof output of current dillo loading the 13M mysql page. Cheers, Johannes

May 23, 2008

memory statistics

by jcid＠dillo.org

Hi Johannes, On Thu, May 22, 2008 at 12:21:51PM +0200, Johannes Hofmann wrote: > Hi, > > to see which part of dillo consumes which amount of memory, I hacked > together a version of dlib.c that counts memory that was allocated via > dMalloc(). A malloc_tag allows to assign the mallocs to specific > parts in the code. In the patch below I use malloc_tag = 1 for cache > stuff, malloc_tag = 2 for text strings that are passed dw2 and > malloc_tag = 0 for everything else. > It's fun to see how memory get's allocated and free'd while loading. > Here is the output once the huge mysql manual page is loaded: > > ====> malloc size 5185114 26967623 6602392 0 > > So that's 6M for text strings, 26M cache and 5M other. > Of course there is also all the dw2 stuff that is not taken into > account here. Yes, and dw2 stuff should be the main part... > BTW, textblock delete's the text strings that are allocated using > malloc(). That's not allowed and might cause unexpected > behaviour on some platforms. This is clearly a bug. A long time ago I thought of dw2 using dlib. Now dw2 is mainly using its own resources. The simple solution would be to let addText to allocate and delete the string. Another way is to study whether is worth to convert dw2 to dlib. It'd be great if we can have gprof profiling working on dillo again. Then use it to see what is the real impact of some optimizations. A long long time ago (in dillo1), I used to heavily optimize functions to avoid extra strdups. It ended making the code a lot more complex and without any noticeable gain. After that we switched to the simple paradigm of having each function free what it allocated. Can you give a hand at enabling profiling again? -- Cheers Jorge.-

May 22, 2008

Uncluttering dillo, part II: the findbar

by jcid＠dillo.org

On Wed, May 21, 2008 at 05:43:05PM +0200, Johannes Hofmann wrote: > Hi Justus, > > On Wed, May 21, 2008 at 12:02:14AM +0200, Justus Winter wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hey everyone :) > > > > attached is a patch that transforms dillos find in page dialog box into > > a firefox style toolbar. There are some issues that I cannot put my > > finger on... see the comments in the event handler. Maybe there's some > > magic about fltks event model that I did not fully understand... then > > again it might be fltks fault. Anyway, I'd be happy for some hints. > > This is really nice! For text search the popup menus are even more > annoying than for entering an url. > > One minor thing. You can make the CheckButton and Input members of > Findbar private if you use static methods for the callbacks instead > of functions. Yes, I agree. -- Cheers Jorge.-

May 22, 2008

Uncluttering dillo, part II: the findbar

by jcid＠dillo.org

On Wed, May 21, 2008 at 12:02:14AM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey everyone :) Hi there! > attached is a patch that transforms dillos find in page dialog box into > a firefox style toolbar. Nice! Committed with some changes. See below. > There are some issues that I cannot put my > finger on... see the comments in the event handler. Maybe there's some > magic about fltks event model that I did not fully understand... then > again it might be fltks fault. Anyway, I'd be happy for some hints. Ok, the comment says: > /* BUG: this is acting funny > * > * 1. figure out why the first EscapeKey is only > * sent to the input widget if it is focused at the time > * 2. ctrl-f ; type foo ; select foo and type bar ; press esc > * => foo is inserted into the input box > */ Fixed both in the committed version. FLTK2 sends the event to handle() and its return value tells whether the event was handled or not. Here, the input widget was handling the event (and making the selection empty) so there was no need to propagate the event upwards, but when the selected text was already empty (second time) there was nothing to do and the event was propagated upwards. The patch was the same as for the location bar. A custom input widget that handles keys in a slightly different way that the native Input widget. In this case (MyInput) we don't handle the escape key and let FLTK pass it upwards, and thus get the desired effect. > Jorge, could you update your coding conventions with respect to c++ > specific language features? Oh yes. I need to find some time though. I've been giving priority to pending patches. The coding conventions, are clearly out of date. At least the C++ part. In this regard we're currently following dw2's style. Can you write a few rules down and send them to me to update the page. The idea is not to be pedantic on style issues, but to define a common style that we can adhere to. -- Cheers Jorge.-

May 22, 2008

memory statistics

by Johannes.Hofmann＠gmx.de

Hi, to see which part of dillo consumes which amount of memory, I hacked together a version of dlib.c that counts memory that was allocated via dMalloc(). A malloc_tag allows to assign the mallocs to specific parts in the code. In the patch below I use malloc_tag = 1 for cache stuff, malloc_tag = 2 for text strings that are passed dw2 and malloc_tag = 0 for everything else. It's fun to see how memory get's allocated and free'd while loading. Here is the output once the huge mysql manual page is loaded: ====> malloc size 5185114 26967623 6602392 0 So that's 6M for text strings, 26M cache and 5M other. Of course there is also all the dw2 stuff that is not taken into account here. BTW, textblock delete's the text strings that are allocated using malloc(). That's not allowed and might cause unexpected behaviour on some platforms. Cheers, Johannes

May 22, 2008

RFC: human interface guidelines

by jcid＠dillo.org

On Tue, May 20, 2008 at 11:55:59PM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey everyone :) > > I was thinking about improving the dillo experience by adding some > functionality / shortcuts people have come to expect. But what people > expect is influenced by their background, their choice of desktop > environment and platform. True. > We could pick one / some user interface guideline(s) ([1] lists some) > and try to adhere to it / them. Or we could pick one popular browser and > copy its 'feel'. Some people love dillo's bindings! :-) The canonical solution is to provide configurable keybindings for the most used functions. Maybe worth trying? ;) -- Cheers Jorge.-

May 21, 2008

[patch] minor memory reduction

by jcid＠dillo.org

On Wed, May 21, 2008 at 05:14:25PM +0200, Johannes Hofmann wrote: > Ok, here comes a second attempt. It works with your test page and > avoids the memore leak. Please test. Committed. -- Cheers Jorge.-

May 21, 2008

Uncluttering dillos UI - getting rid of the dialog boxes

by jcid＠dillo.org

On Wed, May 21, 2008 at 10:10:59AM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Justus Winter wrote: > > Jorge Arellano Cid wrote: > >> On Sat, May 17, 2008 at 05:46:26PM +0200, Justus Winter wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> I thought about dillos fullscreen mode, which is not a fullscreen mode > >>> at all but a "get rid of those panels"-mode. So I decided to rename > >>> those functions and variables accordingly (00-*) > >> Committed. > > > >> With the addition that when the Location is already focused, > >> the text is also selected. This helps as a visual clue and also > >> to quickly get rid of the old URL. > > > >> Note: I used a trick in ::handle() to do it. If you know a > >> better way, please send a patch. > > > > Yes, that's a nice feature indeed. Reading the fltk documentation I came > > up with the attached patch. I am pretty sure that strlen is the wrong > > function when dealing with utf-8 character data, but you get the idea. > > > > Justus > > Looking at the fltk source I realized that Input::size() does exactly > what we want and is also much more efficient. Revised patch is attached. Committed (with the comment). -- Cheers Jorge.-

May 21, 2008