- Dillo-dev - lists.mailman3.com

[patch] don't allocate tagnames on stack

by Johannes.Hofmann＠gmx.de

On Sun, Mar 16, 2008 at 10:47:07AM -0400, Jorge Arellano Cid wrote: > On Thu, Mar 13, 2008 at 09:01:37PM +0100, Johannes Hofmann wrote: > > Hi, > > > > here is another patch that avoids some malloc/free calls. > > > > I decided to completely remove tag_name, and to use Tags[tag_idx]. > Please check the patch in CVS. Cool. That's even better. > > BTW, with regard to these optimizations (which I was very fond of), > profiling showed me that the zen of speed is to attack the main bottleneck... Can you build a statically linked binary with profiling enabled? Here it does not work for some reason, so the timings in the gprof output are bogus. Only the counters work reliably. Cheers, Johannes

March 16, 2008

patch: Re: [Dillo-dev] patch: meta charset changes decoder

by Johannes.Hofmann＠gmx.de

On Sun, Mar 16, 2008 at 09:34:13AM -0400, Jorge Arellano Cid wrote: > On Thu, Mar 13, 2008 at 04:21:42PM +0000, place wrote: > > Jorge wrote: > > > On Fri, Mar 07, 2008 at 06:17:17AM +0000, place wrote: > > > > This is no sort of proper fix whatsoever, but I was tired > > > > of seeing the "would set charset" message. It's actually > > > > surprisingly useful for remote files, since they're generally > > > > still at the javascript-and-css point at the end of the first packet. > > > > > > In CVS there is a new approach that restarts parsing the whole page. > > > It works with local/remote files, and page title. Please test it. > > > > In the past, I've encountered pages that go > > <head> > > <meta http-equiv="content-type" content="text/html; charset=utf-8"> > > <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> > > </head> > > > > Here's code just sticking in a flag when meta charset's been seen. > > Committed a slightly modified version. Please check. ebay.com works again for me. Thanks, Johannes

March 16, 2008

libiconv fix for OpenBSD

by jcid＠dillo.org

Hi, On Sat, Mar 15, 2008 at 12:06:17AM +0100, Christian Kellermann wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> [080314 21:40]: > > > > Committed, but in two places! > > Yeah I have seen it. Why is the same code duplicated? Once should > be enough. My original patch contained such one instance of the > tests... When applying the patch, it failed (I don't know why). After a few tries I decided to patch by hand. Redundance removed, and committed. -- Cheers Jorge.-

March 16, 2008

[patch] don't allocate tagnames on stack

by jcid＠dillo.org

On Thu, Mar 13, 2008 at 09:01:37PM +0100, Johannes Hofmann wrote: > Hi, > > here is another patch that avoids some malloc/free calls. > I decided to completely remove tag_name, and to use Tags[tag_idx]. Please check the patch in CVS. BTW, with regard to these optimizations (which I was very fond of), profiling showed me that the zen of speed is to attack the main bottleneck... -- Cheers Jorge.-

March 16, 2008

patch: Re: [Dillo-dev] patch: meta charset changes decoder

by jcid＠dillo.org

On Thu, Mar 13, 2008 at 04:21:42PM +0000, place wrote: > Jorge wrote: > > On Fri, Mar 07, 2008 at 06:17:17AM +0000, place wrote: > > > This is no sort of proper fix whatsoever, but I was tired > > > of seeing the "would set charset" message. It's actually > > > surprisingly useful for remote files, since they're generally > > > still at the javascript-and-css point at the end of the first packet. > > > > In CVS there is a new approach that restarts parsing the whole page. > > It works with local/remote files, and page title. Please test it. > > In the past, I've encountered pages that go > <head> > <meta http-equiv="content-type" content="text/html; charset=utf-8"> > <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> > </head> > > Here's code just sticking in a flag when meta charset's been seen. Committed a slightly modified version. Please check. -- Cheers Jorge.-

March 16, 2008

multiple-scan images consume a lot of CPU

by Johannes.Hofmann＠gmx.de

On Sat, Mar 15, 2008 at 11:46:59PM +0000, place wrote: > Johannes wrote: > > On Sat, Mar 15, 2008 at 10:16:09PM +0000, place wrote: > > > Johannes wrote: > > > > So as the "TODO" comment in jpeg.c already suggests, we need some > > > > way to switch off multiple-scan when the image is readily available > > > > either from cache, from disk, or from a fast network connection. > > > > > > > > I think some sort of rate limiting would be best that restricts > > > > rescans to - say - once a second. > > > That does not quite work for smaller images. The threshhold would > > need to depend somehow on the total size of the image. > > Do you encounter them much? I was hoping it was too rare to care about. Forget about this comment for now. Your patch below works great for me. I was seeing the problem for example on http://www.tourentipp.de When I went back to that page, it was pretty slow. Thanks, Johannes > > Looking at the bottom of Cache_process_queue(), maybe clients could be > taught to understand CA_Close in place of the last CA_Send for an entry. > Or some interface to get our hands on the cache entry's CA_GotData flag. > I don't know; Jorge will know better. > > > > And I get "Improper call to JPEG library in state 205" but that > > should be easily avoidable. > > Sorry, I was in a bit of a hurry at the time, and I don't have any > multiple scan jpegs now to try it on (could you point me to some?) > > It should have been something more like > > diff -pur dillo2/src/jpeg.c dillo2-cur/src/jpeg.c > --- dillo2/src/jpeg.c 2008-01-16 02:57:32.000000000 +0000 > +++ dillo2-cur/src/jpeg.c 2008-03-15 23:24:21.000000000 +0000 > @@ -293,7 +293,7 @@ static void Jpeg_write(DilloJpeg *jpeg, > * when an image arrives slowly, but should not be used to redisplay > * cached images. > */ > - if (jpeg_has_multiple_scans(&jpeg->cinfo)) > + if ((BufSize < 2000) && jpeg_has_multiple_scans(&jpeg->cinfo)) > jpeg->cinfo.buffered_image = TRUE; > > a_Dicache_set_parms(jpeg->url, jpeg->version, jpeg->Image, > @@ -309,7 +309,7 @@ static void Jpeg_write(DilloJpeg *jpeg, > /* decompression step 5 (see libjpeg.doc) */ > if (jpeg_start_decompress(&(jpeg->cinfo))) { > jpeg->y = 0; > - jpeg->state = jpeg_has_multiple_scans(&jpeg->cinfo) ? > + jpeg->state = jpeg->cinfo.buffered_image ? > DILLO_JPEG_READ_BEGIN_SCAN : DILLO_JPEG_READ_IN_SCAN; > } > } > @@ -355,7 +355,7 @@ static void Jpeg_write(DilloJpeg *jpeg, > > if (jpeg->y == jpeg->cinfo.image_height) { > /* end of scan */ > - if (!jpeg_has_multiple_scans(&jpeg->cinfo)) { > + if (!jpeg->cinfo.buffered_image) { > jpeg->state = DILLO_JPEG_DONE; > break; > } else { > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

March 16, 2008

multiple-scan images consume a lot of CPU

by place＠gobigwest.com

Johannes wrote: > On Sat, Mar 15, 2008 at 10:16:09PM +0000, place wrote: > > Johannes wrote: > > > So as the "TODO" comment in jpeg.c already suggests, we need some > > > way to switch off multiple-scan when the image is readily available > > > either from cache, from disk, or from a fast network connection. > > > > > > I think some sort of rate limiting would be best that restricts > > > rescans to - say - once a second. > That does not quite work for smaller images. The threshhold would > need to depend somehow on the total size of the image. Do you encounter them much? I was hoping it was too rare to care about. Looking at the bottom of Cache_process_queue(), maybe clients could be taught to understand CA_Close in place of the last CA_Send for an entry. Or some interface to get our hands on the cache entry's CA_GotData flag. I don't know; Jorge will know better. > And I get "Improper call to JPEG library in state 205" but that > should be easily avoidable. Sorry, I was in a bit of a hurry at the time, and I don't have any multiple scan jpegs now to try it on (could you point me to some?) It should have been something more like diff -pur dillo2/src/jpeg.c dillo2-cur/src/jpeg.c --- dillo2/src/jpeg.c 2008-01-16 02:57:32.000000000 +0000 +++ dillo2-cur/src/jpeg.c 2008-03-15 23:24:21.000000000 +0000 @@ -293,7 +293,7 @@ static void Jpeg_write(DilloJpeg *jpeg, * when an image arrives slowly, but should not be used to redisplay * cached images. */ - if (jpeg_has_multiple_scans(&jpeg->cinfo)) + if ((BufSize < 2000) && jpeg_has_multiple_scans(&jpeg->cinfo)) jpeg->cinfo.buffered_image = TRUE; a_Dicache_set_parms(jpeg->url, jpeg->version, jpeg->Image, @@ -309,7 +309,7 @@ static void Jpeg_write(DilloJpeg *jpeg, /* decompression step 5 (see libjpeg.doc) */ if (jpeg_start_decompress(&(jpeg->cinfo))) { jpeg->y = 0; - jpeg->state = jpeg_has_multiple_scans(&jpeg->cinfo) ? + jpeg->state = jpeg->cinfo.buffered_image ? DILLO_JPEG_READ_BEGIN_SCAN : DILLO_JPEG_READ_IN_SCAN; } } @@ -355,7 +355,7 @@ static void Jpeg_write(DilloJpeg *jpeg, if (jpeg->y == jpeg->cinfo.image_height) { /* end of scan */ - if (!jpeg_has_multiple_scans(&jpeg->cinfo)) { + if (!jpeg->cinfo.buffered_image) { jpeg->state = DILLO_JPEG_DONE; break; } else {

March 16, 2008

multiple-scan images consume a lot of CPU

by Johannes.Hofmann＠gmx.de

On Sat, Mar 15, 2008 at 10:16:09PM +0000, place wrote: > Johannes wrote: > > I really like the multiple-scan image feature added to dillo > > recently, but it uses quite some CPU and makes it drag slow when > > going back and forth on pages with a lot of images. > > > > So as the "TODO" comment in jpeg.c already suggests, we need some > > way to switch off multiple-scan when the image is readily available > > either from cache, from disk, or from a fast network connection. > > > > I think some sort of rate limiting would be best that restricts > > rescans to - say - once a second. > > > > What do you think? > > Just as a quick experiment, would something like the following do much good? > > diff -pur dillo2/src/jpeg.c dillo2-cur/src/jpeg.c > --- dillo2/src/jpeg.c 2008-01-16 02:57:32.000000000 +0000 > +++ dillo2-cur/src/jpeg.c 2008-03-15 22:10:59.000000000 +0000 > @@ -293,7 +293,7 @@ static void Jpeg_write(DilloJpeg *jpeg, > * when an image arrives slowly, but should not be used to redisplay > * cached images. > */ > - if (jpeg_has_multiple_scans(&jpeg->cinfo)) > + if ((BufSize < 2000) && jpeg_has_multiple_scans(&jpeg->cinfo)) > jpeg->cinfo.buffered_image = TRUE; > > a_Dicache_set_parms(jpeg->url, jpeg->version, jpeg->Image, > That does not quite work for smaller images. The threshhold would need to depend somehow on the total size of the image. And I get "Improper call to JPEG library in state 205" but that should be easily avoidable. Cheers, Johannes

March 16, 2008

multiple-scan images consume a lot of CPU

by place＠gobigwest.com

Johannes wrote: > I really like the multiple-scan image feature added to dillo > recently, but it uses quite some CPU and makes it drag slow when > going back and forth on pages with a lot of images. > > So as the "TODO" comment in jpeg.c already suggests, we need some > way to switch off multiple-scan when the image is readily available > either from cache, from disk, or from a fast network connection. > > I think some sort of rate limiting would be best that restricts > rescans to - say - once a second. > > What do you think? Just as a quick experiment, would something like the following do much good? diff -pur dillo2/src/jpeg.c dillo2-cur/src/jpeg.c --- dillo2/src/jpeg.c 2008-01-16 02:57:32.000000000 +0000 +++ dillo2-cur/src/jpeg.c 2008-03-15 22:10:59.000000000 +0000 @@ -293,7 +293,7 @@ static void Jpeg_write(DilloJpeg *jpeg, * when an image arrives slowly, but should not be used to redisplay * cached images. */ - if (jpeg_has_multiple_scans(&jpeg->cinfo)) + if ((BufSize < 2000) && jpeg_has_multiple_scans(&jpeg->cinfo)) jpeg->cinfo.buffered_image = TRUE; a_Dicache_set_parms(jpeg->url, jpeg->version, jpeg->Image,

March 15, 2008

multiple-scan images consume a lot of CPU

by Johannes.Hofmann＠gmx.de

Hi, I really like the multiple-scan image feature added to dillo recently, but it uses quite some CPU and makes it drag slow when going back and forth on pages with a lot of images. So as the "TODO" comment in jpeg.c already suggests, we need some way to switch off multiple-scan when the image is readily available either from cache, from disk, or from a fast network connection. I think some sort of rate limiting would be best that restricts rescans to - say - once a second. What do you think? Cheers, Johannes

March 15, 2008