-
Notifications
You must be signed in to change notification settings - Fork 517
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
Implement an initial version of property caching #1214
Open
svaarala
wants to merge
6
commits into
master
Choose a base branch
from
property-caching
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains 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
Rough performance testing:
|
20 tasks
svaarala
force-pushed
the
property-caching
branch
2 times, most recently
from
January 24, 2017 04:21
26f8c1b
to
445d45e
Compare
svaarala
force-pushed
the
property-caching
branch
from
January 30, 2017 21:57
445d45e
to
3c5bcdf
Compare
Octane score in master (with duk_hdecenv, duk_hobenv merged) averages 228, rebased against that this branch averages 240. So this simple form of property caching helps ~4% over master. Still, there are several approaches, one to be selected for 2.1.0. |
What is "jerry" in the benchmarks? |
Jerryscript. |
13 tasks
svaarala
force-pushed
the
property-caching
branch
from
February 12, 2017 00:31
3c5bcdf
to
7c60b28
Compare
svaarala
force-pushed
the
property-caching
branch
from
March 9, 2017 00:13
7c60b28
to
7089046
Compare
svaarala
force-pushed
the
property-caching
branch
from
July 30, 2017 02:03
7089046
to
84afa79
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Implement an initial version of property caching where the property cache key is a (generation, object, key) triple. The cache is implemented in GETPROP (the most common property read operation) and the object in the triple is for the starting point of a property lookup. The generation count is a quick way of invalidating the whole cache on any property write or other operation risking cache integrity: entries can be invalidated by a single heap-level generation counter increment without touching the entries themselves. The generation is checked on a cache lookup; no hash chaining is used, and each property lookup hash has only a single slot.
So far this is pretty experimental and some invalidation cases are still missing. The goal is to try to figure out if the approach is workable given all the low level details. Quite possibly some small detail may prevent this from being finished as a viable feature.
Initial results are reasonable however:
for (j = 0; j < arr.length; j++) {...}
loop) runs 2.1 seconds from master and 1.5 seconds with caching.Tasks:
One simple short term improvement is to allow property cache to store a property location (
duk_tval *
) and attributes. Property writes can then be processed without doing an ancestor lookup. If only writable properties are cached, no attribute check is needed either.