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

Faster properties #60

Merged
merged 14 commits into from
Jan 2, 2022
Merged

Faster properties #60

merged 14 commits into from
Jan 2, 2022

Conversation

veselink1
Copy link
Owner

This PR aims to fix the slow compilation uncovered in #58.

An optimisation is added to property-related utilities. The optimisation is based on the presumption that getters and setters are reflected (via the RELF_AUTO or REFL_FUNC macros) one after the other. The optimisation consists of checking the neighbouring members first, before resorting to a linear search.

Applies to:

REFL_AUTO(
    type(Point),
    func(get_x, property()),
    func(set_x, property()),
    func(get_y, property()),
    func(set_y, property())
)

But does NOT apply to:

REFL_AUTO(
    type(Point),
    func(get_x, property()),
    func(get_y, property()),
    func(set_x, property()),
    func(set_y, property())
)

I have added a bench/ tree, which will be used for benchmarks. Only one benchmark exists at the moment - bench-large-pod.cpp, which iterates over the members of a large POD with getters and setters and matches property getters to setters via get_reader/writer.

Results of compilation of bench-large-pod.cpp:

Without the optimisation:

Command being timed: "make large-pod"
User time (seconds): 41.69
System time (seconds): 1.01
Percent of CPU this job got: 99%
Maximum resident set size (kbytes): 3440424

With the optimisation:

Command being timed: "make large-pod"
User time (seconds): 10.38
System time (seconds): 0.42
Percent of CPU this job got: 99%
Maximum resident set size (kbytes): 1319484

@veselink1 veselink1 changed the title [WIP] Faster properties Faster properties Jan 2, 2022
This benchmark should help diagnose #58.

On my machine with GCC 9.3, compilation for LargePod
with 100 properties used 3.4 GiB RAM and ran in 48s.

Complation for LargePod with 200 properties (PROPERTIES_2X)
used all of the system memory available to the VM (8 GiB),
and terminated after 5m30s.

This points to horrendeous scalability issues with
get_reader/has_writer, likely caused by the theoretically
quadratic factor blowup of the compilation of ProcessClass().
(Would have been quadratic if this was executed at runtime,
not sure how to properly calculate and describe it in this case).
Added an optimisation to the get|has_reader|writer methods
which checks the neighbouring members first, before deferring
to a linear search (very slow, see #58).

Also adds the REFL_DISALLOW_SEARCH_FOR_RW define. If defined,
linear search in the above situations is not permitted and
compilation will fail.
The implementation of the linear search used by the
property utilities was refactored to reduce compilation
times and reduce the number of template instantiations
that the compiler has to make.
@veselink1
Copy link
Owner Author

With the latest changes, compilation times for bench-large-pod.cpp (100 properties) have improved as follows:

Compiler (-02) Time (v0.12.1) Time (faster-properties) Memory (v0.12.1) Memory (faster-properties)
gcc 9 39.44s 4.51s 3620956 KB 567980 KB
clang 10 49.65s 3.56s 2489668 KB 741472 KB

Time to compile was reduced by at least 88% (in the case of gcc) and peak memory usage was reduced by at least 84% (in the case of gcc).

bench-large-pod-search.cpp saw even more improvement. This version of the above benchmark exercises the slower code path in get_reader/writer. It could not compile in my VM due to OOM (8 GiB RAM available). It now compiles happily and a little slower than the regular version (which has getters and setters defined next to each other - a heuristic for which was added in 3547e6e).

Compiler (-02) Time (v0.12.1) Time (faster-properties) Memory (v0.12.1) Memory (faster-properties)
gcc 9 N/a 8.51s N/a 848516 KB
clang 10 N/a 10.20s N/a 1293552 KB

@veselink1
Copy link
Owner Author

Closes #58.

@veselink1 veselink1 merged commit 00b3497 into master Jan 2, 2022
@veselink1 veselink1 deleted the faster-properties branch January 2, 2022 16:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants