5 ms·

Huh. Why is this so slow? According to Chrome, it took 704 milliseconds from clicking the "show" button on "Windows XP" to displaying the results. No network ca

Huh. Why is this so slow? According to Chrome, it took 704 milliseconds from clicking the "show" button on "Windows XP" to displaying the results. No network calls at all. A whole 525ms of script evaluation. Modern computer, thousand row table, wouldn't expect it to take that long.

lucb1e 7y ago
Works fine for me on an average laptop with latest stable Firefox.
- mehrdadn 7y ago
  Try "Show All".
  - scomp 7y ago
    200ms on Firefox clicking show all.
  - wvenable 7y ago
    Seems instantaneous on Firefox for me.
    - mehrdadn 7y ago
      Really?! It isn't instantaneous for me, even on Firefox 62 (Windows). Takes some half a second or so.
      - wvenable 7y ago
        I'm on Firefox 68.0.2 on Windows 10. I can click "Show All" and "Hide All" over and over and there is hardly any delay. Maybe you should upgrade to the latest and see if it makes a difference.
        mehrdadn 7y ago
        Interesting, thanks for mentioning this! It seems to be something with my profile, because a fresh profile is also definitely faster (maybe 200-300ms just eyeballing). The latest unbranded build I got [1] also seems about the same if not faster (maybe around 200ms). Definitely not "instantaneous", but I'll definitely track this down. UPDATE: At least 3 of the culprits seem to be MutationObservers from my own extensions (as in, from extensions that I have written for myself) that have {childList: true, subtree: true}! I guess I will have to optimize them. :-) [1] https://queue.taskcluster.net/v1/task/Uht_zkkPThu384OAHNPwdA/runs/0/artifacts/public/build/target.zip https://queue.taskcluster.net/v1/task/Uht_zkkPThu384OAHNPwdA...
mehrdadn 7y ago
Not sure, but innerHTML seems to be taking a long time, in a call that loops over the results of getElementsByName. Given that getElementsByName doesn't return a real array, is it possible internally it's doing bookkeeping to make sure the iteration is still over the same set of nodes? Or alternatively maybe modifying innerHTML is just slow.
nitwit005 7y ago
Not an answer exactly, but I did some work with large HTML tables for an analytics project, and I did learn browsers struggle with larger tables. After doing a number of optimizations, our 2000 row table took 1.2 seconds for chrome to insert the elements (purely the appendChild call). That was down from around 2.6 before trimming down the HTML.
prolurker 7y ago
Tables layout is generally complex and slow, only hiding the text with CSS feels very fast. Once layout is involved even without looping to set innerHTML it becomes a lot slower.

lucb1e 7y ago

Works fine for me on an average laptop with latest stable Firefox.

mehrdadn 7y ago
Try "Show All".
- scomp 7y ago
  200ms on Firefox clicking show all.
- wvenable 7y ago
  Seems instantaneous on Firefox for me.
  - mehrdadn 7y ago
    Really?! It isn't instantaneous for me, even on Firefox 62 (Windows). Takes some half a second or so.
    - wvenable 7y ago
      I'm on Firefox 68.0.2 on Windows 10. I can click "Show All" and "Hide All" over and over and there is hardly any delay. Maybe you should upgrade to the latest and see if it makes a difference.
      - mehrdadn 7y ago
        Interesting, thanks for mentioning this! It seems to be something with my profile, because a fresh profile is also definitely faster (maybe 200-300ms just eyeballing). The latest unbranded build I got [1] also seems about the same if not faster (maybe around 200ms). Definitely not "instantaneous", but I'll definitely track this down. UPDATE: At least 3 of the culprits seem to be MutationObservers from my own extensions (as in, from extensions that I have written for myself) that have {childList: true, subtree: true}! I guess I will have to optimize them. :-) [1] https://queue.taskcluster.net/v1/task/Uht_zkkPThu384OAHNPwdA/runs/0/artifacts/public/build/target.zip https://queue.taskcluster.net/v1/task/Uht_zkkPThu384OAHNPwdA...

mehrdadn 7y ago

Not sure, but innerHTML seems to be taking a long time, in a call that loops over the results of getElementsByName. Given that getElementsByName doesn't return a real array, is it possible internally it's doing bookkeeping to make sure the iteration is still over the same set of nodes? Or alternatively maybe modifying innerHTML is just slow.

nitwit005 7y ago

Not an answer exactly, but I did some work with large HTML tables for an analytics project, and I did learn browsers struggle with larger tables. After doing a number of optimizations, our 2000 row table took 1.2 seconds for chrome to insert the elements (purely the appendChild call). That was down from around 2.6 before trimming down the HTML.

prolurker 7y ago

Tables layout is generally complex and slow, only hiding the text with CSS feels very fast. Once layout is involved even without looping to set innerHTML it becomes a lot slower.