Very high lag when many (>100's) nodes dynmaically inserted

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Go to a page on Wikipedia where you can sort data. example : 
http://en.wikipedia.org/wiki/List_of_political_and_geographic_subdivisions_by_to
tal_area_(all)
2. Try to sort the data by clicking on the arrow near Area (km²)

What is the expected output? What do you see instead?
The array should be sorted in less than a second.
Instead, Chrome lags so much that I have to kill the page. Disabling the 
extension fixes the problem. Note : on smaller arrays, I can see the (correct) 
result of the sorting after waiting a few seconds. (example : 
http://en.wikipedia.org/wiki/List_of_political_and_geographic_subdivisions_by_to
tal_area_from_1,000_to_3,000_km%C2%B2)

Which browser are you using, Firefox or Chrome? On what operating system?
Chrome dev 9.0.576.0. I haven't tested on the main branch of Chrome.

Please provide any additional information below.
I guess the extension tries to parse the page everytime an entry is sorted 
which causes a lot of computations. If the problem is hard to fix, it would be 
convenient if there was a way to keep the extension in a "passive" state where 
it doesn't parse pages until the user clicks on the extension icon.

Original issue reported on code.google.com by tvan...@googlemail.com on 18 Nov 2010 at 6:43

[GoogleCodeExporter]

Not related to furigana injector. Did you mean to post to the chromium issues 
list?

Original comment by akira%ya...@gtempaccount.com on 19 Nov 2010 at 1:19

• Changed state: Invalid
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

I looked a little more into the problem since I'm not completely sure whether 
it is related to chrome or to the extension.

If I create a very simple html page with only a function like this called when 
clicking a button,

for(var i = 0; i < 1000; i++)
{
    document.getElementById('somediv').appendChild(document.createTextNode('Some random text.'));
}

(which is basically what the code on wikipedia does), then the lag will occur 
(and even more after two or three clicks). If I understand this right, it is 
because the whole page is parsed every time an element is modified when looking 
for kanji (and if one is found, then the extension icon appears in the 
omnibar). However there is no problem when doing the same thing on firefox. 
Since the extension icon is always active in the firefox version, I guess the 
pages aren't parsed at all until the user clicks on the icon.
Is there a reason why the behaviour differs in chrome and firefox ? I get the 
feeling it is a waste of computation time to parse every single page before the 
user decides whether or not he wants to add the furigana.

Please correct me if I said anything wrong.

Original comment by tvan...@googlemail.com on 19 Nov 2010 at 3:43

[GoogleCodeExporter]

Forgive me! I made some assumptions the other day which were quite wrong. You 
stuck with it and you deserve double credit for this.

The case here is a page that contains no japanese, and via javascript it 
inserts a lot of nodes on that sorting. Furigana Injector listens *forever* on 
every page until it detects japanese. This is to handle the case of AJAX pages 
that load content asynchronously after the original DOM load event. When it 
does detect some japanese it shows the icon and deletes the listener. In the 
case of the table-sorter things are getting overloaded- bit of a surprise 
honestly, I thought better of Chrome.

I'm very keen that the icon not been shown on pages that don't contain japanese 
because A) many people will be confused and B) screen real estate will be used 
up unnecessarily. Also, by detecting japanese before loading all the scripts 
I'm making Chrome faster on every page than it would be otherwise.

The reason it's not the way Firefox is simply that they have different process 
and memory model; different possibilities (and principles) for GUI; and 
different API.

I will choose a better way to detect later-inserted nodes. First choice is to 
queue all inserted nodes and only perform a check once a second, rather than at 
every event.

Original comment by akira%ya...@gtempaccount.com on 21 Nov 2010 at 3:38

• Changed state: Accepted
• Added labels: Type-Defect, Priority-High, Broswer-Chrome

[GoogleCodeExporter]

Delaying inspection is partially helping but the sheer number of new, trivially 
small nodes is causing a lot of load. I'm guessing this is because I've used an 
XPath expression to search for japanese chars. Let's see if I can't improve 
this- either by making an iterator in simpler javascript, or a fancier idea is 
to find the lowest common parent of all inserted nodes (after a 1 sec delay) 
and use the XPath search on that.

Original comment by akira%ya...@gtempaccount.com on 21 Nov 2010 at 4:04

[GoogleCodeExporter]

New chrome version uploaded! (1.1.2)

Testing of dynamically-inserted text is being asynchronously queued and then 
tested in batch. But the biggest time improvement has been to drop the XPath 
expression and simply use the <Element>.innerText property to get to text.

Original comment by akira%ya...@gtempaccount.com on 23 Nov 2010 at 2:16

• Changed title: Very high lag when many DHTML node inset
• Changed state: Fixed

[GoogleCodeExporter]

Original comment by akira%ya...@gtempaccount.com on 23 Nov 2010 at 2:17

• Changed title: Very high lag when many (>100's) nodes dynmaically inserted

[GoogleCodeExporter]

Thanks a lot for fixing this ! It seems to work perfectly now.

Original comment by tvan...@googlemail.com on 23 Nov 2010 at 7:35

[GoogleCodeExporter]

No, thank you tvannet! You did some ace debugging and stuck with it when I was 
an idiot who assumed his code wasn't related to the issue.

Original comment by akira%ya...@gtempaccount.com on 24 Nov 2010 at 1:03