-
Notifications
You must be signed in to change notification settings - Fork 395
Implement ArrayDeque using scala.Array. #5164
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
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For
ArrayDeque
, it does not seem like we rely all that much on the growability ofjs.Array
s. The only place that grows isensureCapacityForAdd()
. It always doubles the size of the internal array. It's unlikely that the underlying VM could do a better job than just reallocating at about the same moments.Perhaps it would be better to just always use
Array[AnyRef]
, even on JS. That would avoid complicating the logic, which in this class is particularly dense already.@gzm0 WDYT?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For comparison, I wrote a
Array[AnyRef]
(even on JS) version b73e8a1And, I wrote a micro-benchmark for
ArrayDeque
, and compare the two implementation on JS (scala.Array vs js.Array), each benchmark basically add/poll integer 10000 times.tanishiking/scalajs-benchmarks@13cd090
The result shows that,
js.Array
is still slightly faster thanscala.Array
in most cases. However, considering the complexity of the program, the difference may be negligible.https://colab.research.google.com/drive/17eevbKILkGiT21uqWCDuD3KAkj-de6BT?usp=sharing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Were those benchmarks done in fullLink?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was in
fastLink
, infullLink
scala.Array and js.Array has a bit smaller difference in addLast benchhttps://colab.research.google.com/drive/17eevbKILkGiT21uqWCDuD3KAkj-de6BT?usp=sharing
it's interesting that, with scala.Array impl, FIFO and LIFO cases (last two benchmarks) are consistently faster than js.Array
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the overall sentiment, that just using
scala.Array
for JS as well might be worthwhile.It seems that the investigation here as already gone beyond gut feeling, so I guess we can let the numbers speak.
The current benchmarks do look like there is some overhead not related to resizing. For example, I'd expect
peekFirst_Repeatedly
to not cause any mutations. Do we have an understanding of where these come from?Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, it was my benchmark programs' fault, the
peekFist/peekLast
benchmarks anyway add 10000 items to the queue, and resize happened.Updated the benchmark to add only 16 items to the queue (not to trigger resizing) and peek first/last 10000 times. tanishiking/scalajs-benchmarks@825063f
The result shows that there's really no difference between js.Array and scala.Array 👍
I think the difference in poll comes from resizing too, since it push 10000 items (resize happen) and then poll 10000 times.