Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation recommendations #14

Open
dead-claudia opened this issue Jul 28, 2020 · 6 comments
Open

Implementation recommendations #14

dead-claudia opened this issue Jul 28, 2020 · 6 comments
Labels
enhancement New feature or request

Comments

@dead-claudia
Copy link

This is more an FYI than a specific feature request. For ideal performance, implementations should consider the following:

  • Using a specialized append-only set rather than the built-in ES one, as only "has" and "add" are ever used.
  • For integer arrays, using a sparse bit set rather than a traditional set to improve both speed and memory.
  • For polyfills, using the obvious Array.from(set) rather than a parallel array.
@TechQuery TechQuery added the enhancement New feature or request label Jul 29, 2020
@TechQuery
Copy link
Collaborator

  • For polyfills, using the obvious Array.from(set) rather than a parallel array.

"a parallel array" means [...new Set([])] ?

@dead-claudia
Copy link
Author

I was referring to converting the set into an array at the end rather than building an array alongside the set.

@hax
Copy link
Member

hax commented Sep 10, 2020

@isiahmeadows Not sure whether they would have perf difference...

@dead-claudia
Copy link
Author

It may, considering CPU pipelines and such - with a specialized data structure, it becomes effectively just a copy, and CPUs like that. They can also allocate only the memory needed for the returned result in one single step as opposed to potentially multiple allocations in the loop, thus wasting less memory and reducing the overhead in the loop itself.

@hax
Copy link
Member

hax commented Sep 10, 2020

It may also slower, especially in embed js engines. :-P

@dead-claudia
Copy link
Author

Part of why I said "should consider" and not that it's an outright recommendation like using hash tables for Map - I know embedded and server engines don't work the same way and have two different sets of needs, and space constraints may very well preclude using those recommendations. (For BigInts, there's been some recent chatter in v8-dev of potentially creating a split implementation for multiplication and division of large BigInts to cater to both embedded and high-performance needs, and factoring it out into a standalone library for other runtimes to use. So there's precedent.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants