On Fri, Jun 20, Jorge Arellano Cid wrote:
On Fri, 20 Jun 2003, Frédéric Bothamy wrote:
Not sure if the problem is the same, but I have noticed this behaviour when I load a big page with an anchor (or is it a reference?) in the address, eg:
http://ftp-master.debian.org/testing/update_excuses.html#kdelibs
(WARNING: 853 Kb). It eventually finishes loading the page but it can take a HUGE amount of time (several minutes whereas the same page without '#kdelibs' only takes about 10 to 15 seconds).
This is another problem!
IIRC Sebastian posted a comment about this sometime ago, but although I searched for, I didn't find the post :(
I don't remember it, the problem is actually new to me. Anyway, I've looked a bit at it, read on.
After reviewing it myself (the huge page with anchor problem), I developed a small patch that more or less solves the problem (makes the anchored URL to load two times slower, but it works). -- I'm still working on it.
Profiling shows that dillo is most of the time in Dw_gtk_viewport_update_anchor_rec (and related functions). To avoid searching recursively for the widget which contains the anchor, I've tested to add an hashtable to the viewport itself, which works quite well. Dw_gtk_viewport_update_anchor itself is called quite a couple of times (1511 times in my 200k test page), but AFAIS, this is correct.
The problem is similar to what we had before incremental rewraping. The anchor (aka. "fragment") code falls inside an exponential algorithm so it dies hogging (unless you have exponential patience!).
Not exactly, it is quadratic, or cubic (too lazy to be correct), but it's still bad enough. Sebastian