4 ms·
I tried this on a spare time project[1]. Runtime in a quick test went down from 14.5 to 12.2 secs on macOS! So a solid ~15% by changing the allocator to jemall
by virtualritz 6y ago
I tried this on a spare time project[1]. Runtime in a quick test went down from 14.5 to 12.2 secs on macOS!
So a solid ~15% by changing the allocator to jemalloc.
However, I now have a segfault w/o a stack trace when the data gets written at the end of the process.
Possibly something fishy in some `unsafe{}` code of a dependent crate of mine that the different allocator exposed. :]
Still – no stack trace at all is very strange in Rust when one runs a debug build with RUST_BACKTRACE=full.
[1] https://github.com/virtualritz/rust-diffusion-limited-aggregation https://github.com/virtualritz/rust-diffusion-limited-aggreg...
- saagarjha 6y agoI have found that jemallocator is currently broken on macOS Catalina, so that might be the problem. If you can reproduce this issue reliably, I'd love to hear about it because I can't myself unless I use a very specific toolchain that produces -O3 binaries that are a real pain to work with.
- virtualritz 6y agoIt's 100% reproducible. Just check out the previous to last commit on master on the github repo I linked to and run the tool with any command that invokes the nsi crate. Eg.: > rdla dump foo.nsi should produce the segfault before exiting the process. Is there a jemallocator ticked where to attach a report for this?
- saagarjha 6y agoThanks! I think you found the jemallocator bug, so I'll try your project and follow up there.
- virtualritz 6y agoI think that bug may be fixed in jemalloc by now. The version of jemalloc that the jemalloc-sys crate tracks is from two years ago. I tried bumping jemalloc to latest master but that makes the jemalloc-sys build fail (trivially with a missing script but still). Also there is this: https://github.com/gnzlbg/jemallocator/issues/136 https://github.com/gnzlbg/jemallocator/issues/136