Performance bottleneck in scrollbarWidth?

[ineuwirth]

Hi,

I am looking forward to seeing your opinion whether I misuse the library or have found a performance issue.

We currently use floatThead in a large static single-page documentation containing 39 tables. Simply iterating over all the tables took around 10 seconds (my workstation: Core i5, 16GB RAM).

I applied a simple optimization by skipping the tables that have a height less than $(window).height(). It reduced the time taken to ~8 seconds. Statistics about the number of rows of the remaining tables:

• number: 29
• avg: 19
• min: 3
• max: 83

Deferring the script did not help too much either because the browser hung. As rendering the page was still pretty slow I traced the code down to the suspicious scrollbarWidth() call. It is called for each table and forces reflow (darker purple bars). See:

If I cached the result of scrollbarWidth() and passed to the subsequent floatThead() calls then the bottleneck disappeared:

I have not found any workaround without changing the floatThead script itself.

JSFiddle: https://jsfiddle.net/8nzx6Lhm/

• Chrome 64.0.3282.140 (Official Build) (64-bit)
• Windows 10
• jQuery 1.9.0
• floatThead 2.0.3

[mkoryak]

Wow nice, looks like you found a problem here. Do you want to submit a PR? Otherwise you will have to wait for me for a few hours. Either way this is meaty enough to warrant a new version. Thanks!

…

On Feb 7, 2018 7:13 AM, "Istvan Neuwirth" ***@***.***> wrote: Hi, I am looking forward to seeing your opinion whether I misuse the library or have found a performance issue. We currently use *floatThead* in a large static single-page documentation containing 39 tables. Simply iterating over all the tables took around 10 seconds (my workstation: Core i5, 16GB RAM). I applied a simple optimization by skipping the tables that have a height less than $(window).height(). It reduced the time taken to ~8 seconds. Statistics about the number of rows of the remaining tables: - number: 29 - avg: 19 - min: 3 - max: 83 Deferring the script did not help too much either because the browser hung. As rendering the page was still pretty slow I traced the code down to the suspicious scrollbarWidth() call. It is called for each table and forces reflow (darker purple bars). See: [image: image] <https://user-images.githubusercontent.com/6502015/35915711-35c70cbc-0c08-11e8-9643-f5ef73a6400a.png> If I cached the result of scrollbarWidth() and passed to the subsequent floatThead() calls then the bottleneck disappeared: [image: image] <https://user-images.githubusercontent.com/6502015/35915724-41c2a88c-0c08-11e8-9e12-787a38835f57.png> I have not found any workaround without changing the *floatThead* script itself. JSFiddle: https://jsfiddle.net/8nzx6Lhm/ - Chrome 64.0.3282.140 (Official Build) (64-bit) - Windows 10 - jQuery 1.9.0 - floatThead 2.0.3 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#402>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXbSfnxLZit0hXMaymW21Z8ZlBqyz32ks5tSZNkgaJpZM4R8nIc> .

[mkoryak]

There is other feature detection that I do in there that should become memoized as well

…

On Feb 7, 2018 7:49 AM, "Misha Koryak" ***@***.***> wrote: Wow nice, looks like you found a problem here. Do you want to submit a PR? Otherwise you will have to wait for me for a few hours. Either way this is meaty enough to warrant a new version. Thanks! On Feb 7, 2018 7:13 AM, "Istvan Neuwirth" ***@***.***> wrote: > Hi, > > I am looking forward to seeing your opinion whether I misuse the library > or have found a performance issue. > > We currently use *floatThead* in a large static single-page > documentation containing 39 tables. Simply iterating over all the tables > took around 10 seconds (my workstation: Core i5, 16GB RAM). > > I applied a simple optimization by skipping the tables that have a height > less than $(window).height(). It reduced the time taken to ~8 seconds. > Statistics about the number of rows of the remaining tables: > > - number: 29 > - avg: 19 > - min: 3 > - max: 83 > > Deferring the script did not help too much either because the browser > hung. As rendering the page was still pretty slow I traced the code down to > the suspicious scrollbarWidth() call. It is called for each table and > forces reflow (darker purple bars). See: > > [image: image] > <https://user-images.githubusercontent.com/6502015/35915711-35c70cbc-0c08-11e8-9643-f5ef73a6400a.png> > > If I cached the result of scrollbarWidth() and passed to the subsequent > floatThead() calls then the bottleneck disappeared: > > [image: image] > <https://user-images.githubusercontent.com/6502015/35915724-41c2a88c-0c08-11e8-9e12-787a38835f57.png> > > I have not found any workaround without changing the *floatThead* script > itself. > > JSFiddle: https://jsfiddle.net/8nzx6Lhm/ > > - Chrome 64.0.3282.140 (Official Build) (64-bit) > - Windows 10 > - jQuery 1.9.0 > - floatThead 2.0.3 > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#402>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAXbSfnxLZit0hXMaymW21Z8ZlBqyz32ks5tSZNkgaJpZM4R8nIc> > . >

[ineuwirth]

Thank you for your prompt feedback. I would be happy to submit a PR however I could do it tomorrow at the earliest.

[mkoryak]

I looked at the source, the other feature detection is all memorized already.

[mkoryak]

Thanks for the PR. Looks like I have one more to merge, and after that ill cut a new release.

[ineuwirth]

Thank you @mkoryak

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.