Match or exceed v1 performance#580
Open
jhollinger wants to merge 20 commits intorelease-2.0from
Open
Conversation
jhollinger
force-pushed
the
jh/release-2.0-faster
branch
4 times, most recently
from
cf26f1a to
43f7db0
Compare
jhollinger
force-pushed
the
jh/release-2.0-faster
branch
10 times, most recently
from
ecc17e3 to
9be161e
Compare
Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
jhollinger
force-pushed
the
jh/release-2.0-faster
branch
6 times, most recently
from
f3556f1 to
6d2c7c1
Compare
… internal details Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
jhollinger
force-pushed
the
jh/release-2.0-faster
branch
2 times, most recently
from
98b34e4 to
5841499
Compare
jhollinger
force-pushed
the
jh/release-2.0-faster
branch
2 times, most recently
from
30abb0f to
22c9256
Compare
Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
Add a context-free serialization path for the common case where no extension hooks, conditionals, default values, formatters, or Proc extractors are configured. Previously, every call to `serialize` allocated a `Context::Field` and a `Context::Parent` struct unconditionally — even when nothing in the serialization loop ever read them. Together these accounted for ~22% of all object allocations and caused V2 to trigger 2× more GC runs than V1 under the same workload. Changes: - Add `Extractors::Property.extract_simple` to extract field values directly from an object/hash without a Context::Field - Precompute `@needs_field_ctx` at blueprint load time in `find_used_hooks!` (requires `finalize_fields!` to run first, hence the reorder in `initialize`) - Branch to `serialize_fast` when `@needs_field_ctx` is false, skipping the Context::Field allocation entirely - Make `Context::Parent` lazy in both paths — created at most once per `serialize` call, only when an association field is actually encountered Result on 500 widgets × 50 iterations (30 fields, 10 object associations, 5 collection associations): - Allocations: −23% (3.3M → 2.56M objects) - GC runs: −26% (85 → 63) - Context::Field: eliminated from hot path (75k → 0 samples) - Context::Parent: eliminated from hot path (75k → ~10 samples) V2 now allocates fewer objects than V1 for the common case. Made-with: Cursor Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
Reduce V2 serializer allocations by ~23% via fast path
jhollinger
force-pushed
the
jh/release-2.0-faster
branch
from
22c9256 to
6057122
Compare
…le* speed but should be easier to test & maintain Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
jhollinger
force-pushed
the
jh/release-2.0-faster
branch
from
68bcf6d to
39cb22a
Compare
…wn blueprint options Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
jhollinger
force-pushed
the
jh/release-2.0-faster
branch
from
0bdcc75 to
719637c
Compare
…rnal but prefix private fields with an "_" Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
jhollinger
force-pushed
the
jh/release-2.0-faster
branch
from
9d5c4be to
6b70e88
Compare
…lds` Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
jhollinger
force-pushed
the
jh/release-2.0-faster
branch
from
8e86a45 to
4da5c95
Compare
Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
Will make if/unless/default/etc options Procs and field blocks behave more similarly to V1's. They can still access the Blueprint instance through `ctx`. Format blocks still use instance_exec, b/c otherwise they couldn't access the Blueprint. And that's new functionality so no compatibility concerns. Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
jhollinger
force-pushed
the
jh/release-2.0-faster
branch
from
0232c77 to
ca1a0e9
Compare
Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
…il after that hook runs Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
…sn't make sense to allow classes or procs Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
jhollinger
force-pushed
the
jh/release-2.0-faster
branch
from
499e3ad to
01c168d
Compare
… place now Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
…e time/memory) Signed-off-by: Jordan Hollinger <jordan.hollinger@procore.com>
jhollinger
force-pushed
the
jh/release-2.0-faster
branch
from
01c168d to
aad5212
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
After V1's recent perf improvements, V2's perf was no longer looking so good. These changes make V2 competitive again:
Perf varies with the number of fields, objects, and collections. It can also vary between the top-level serialization being a collection or object (collections are faster b/c some overhead is shared across loops). Use of extensions also caries some overhead (none were used in the measurements below).
One thing we lost here is the ability to have extensions that are initialized per-render. I think it's possible to add again, but it will be more complicated, so IMHO we should wait until someone needs it.