initTable is slow, can we lazily load parts as they're needed?
See original GitHub issueOn my fairly fast gaming desktop it’s over a frame:
It looks like initTable
could be made so only load chunks of table
as necessary, splitting it into 32 parts (66636/32=2048 codepoints) would probably make it have minimal impact on frames following a load.
Issue Analytics
- State:
- Created 5 years ago
- Comments:29 (29 by maintainers)
Top Results From Across the Web
Lazy Loading: How It Decreases Load Time and Increases ...
Lazy loading reduces the time it takes for a web page to open because the browser only loads a fraction of the content...
Read more >Use lazy loading to improve loading speed - web.dev
This post explains lazy loading and why you might want to lazy-load elements on your site.
Read more >What is Lazy Loading | Lazy vs. Eager Loading
Lazy loading is the practice of delaying load or initialization of resources or objects until they're actually needed to improve performance and save...
Read more >Effects of Too Much Lazy Loading on Web Performance
According to many studies, there are two main advantages that any developer can achieve by lazy loading. Reduced page load time (PLT): We...
Read more >Lazy loading components and code splitting in Vue.js
Vue.js handles loading components lazily with routes, so on the DOM you can load components only when they are needed through routes.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@skprabhanjan Another approach - programmatically walk the 0 and 2 width codepoints to fill the table. Instead of repeatingly doing the bisect and
isWideBMP
eval for every single codepoint from 0 to 65536 we can simply create the lookup table cheaper by this:This lowers the creation cost down to 1.5 ms for the whole table and can be done during lib initialization. This coupled with the slightly more expensive 64k table and we have really nice speedup at initialization and during runtime. 😸
@Tyriar Mission accomplished?
Edit: With
.subarray
instead of the loops the above table creation runs in 0.2 ms, lol.Fixed with #1789.