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

Make performance counter optional #9

Closed
phil-opp opened this issue Jan 9, 2016 · 2 comments
Closed

Make performance counter optional #9

phil-opp opened this issue Jan 9, 2016 · 2 comments

Comments

@phil-opp
Copy link
Contributor

phil-opp commented Jan 9, 2016

The perfcnt module and the corresponding build script make the build very slow. On my machine, a complete build takes over a minute.

One problem are the additional dependencies:

Compiling winapi v0.2.5
Compiling winapi-build v0.1.1
Compiling raw-cpuid v2.0.0
Compiling byteorder v0.3.13
Compiling advapi32-sys v0.1.2
Compiling phf_shared v0.7.10
Compiling rustc-serialize v0.3.16
Compiling phf v0.7.10
Compiling libc v0.2.4
Compiling rand v0.3.12
Compiling phf_generator v0.7.10
Compiling phf_codegen v0.7.10
Compiling csv v0.14.3
Compiling num v0.1.30
Compiling serde v0.6.7
Compiling serde_json v0.6.0
Compiling x86 v0.5.0

Without the build script and the perfcnt module, only the raw-cpuid dependency is left:

Compiling x86 v0.5.0
Compiling raw-cpuid v2.0.0

And the build completes in under 4 seconds on my machine.

Therefore it would be great if the perfcnt module were optional. We could use a cargo feature to make it opt-in or opt-out.

I have created a patch and would be happy to send a PR if desired!

@gz
Copy link
Owner

gz commented Jan 10, 2016

Thanks for making this patch. The compile time for the crate bothers me as well. Are the dependencies really the problem for you (they should be cached after the first build right?) or is it the long runtime of the build.rs file? In case of the second I wonder if we can fix it with rust-lang/cargo#2134 by specifying the build.rs dependencies so it does not regenerate the hash-tables every time?

gz added a commit that referenced this issue Jan 10, 2016
This should reduce compilation time slightly by avoiding to invoke
the build script every time. Altough the big problem with Issue #9
seems to be the compilation of the crate itself that is slowed down
by compiling the huge static tables generated by phf.
@gz
Copy link
Owner

gz commented Jan 10, 2016

I did a quick test with the rerun-if-changed attribute but the effect is small as the main time saver is really the compilation of the x86 crate. I'm happy to merge the pull request that makes the performance counters optional. Thanks.

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

No branches or pull requests

2 participants