This repository was archived by the owner on Apr 22, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 22, 2023. It is now read-only.
Start linking against jemalloc? #5339
Description
Out of curiosity I recently compared the buffer creation benchmarks with and without jemalloc (3.3.1, default configuration options) and this is what I saw (Linux x86_64):
- master branch @ c773124:
-
without jemalloc:
buffers/buffer-creation.js buffers/buffer-creation.js type=fast len=10 n=1024: 4073.2 Memory usage: 11,567,104 buffers/buffer-creation.js type=fast len=1024 n=1024: 1865.8 Memory usage: 102,019,072 buffers/buffer-creation.js type=slow len=10 n=1024: 878.22 Memory usage: 70,164,480 buffers/buffer-creation.js type=slow len=1024 n=1024: 595.72 Memory usage: 206,356,480 -
with jemalloc:
buffers/buffer-creation.js buffers/buffer-creation.js type=fast len=10 n=1024: 4052.4 Memory usage: 11,718,656 buffers/buffer-creation.js type=fast len=1024 n=1024: 1737.1 Memory usage: 30,728,192 buffers/buffer-creation.js type=slow len=10 n=1024: 750.70 Memory usage: 64,860,160 buffers/buffer-creation.js type=slow len=1024 n=1024: 606.87 Memory usage: 39,362,560
-
- master branch @ c773124 with current patches from external memory allocation management #4964 applied:
-
without jemalloc:
buffers/buffer-creation.js buffers/buffer-creation.js type=fast len=10 n=1024: 4391.9 Memory usage: 11,493,376 buffers/buffer-creation.js type=fast len=1024 n=1024: 2923.7 Memory usage: 48,689,152 buffers/buffer-creation.js type=slow len=10 n=1024: 2307.6 Memory usage: 11,399,168 buffers/buffer-creation.js type=slow len=1024 n=1024: 1762.7 Memory usage: 40,456,192 -
with jemalloc:
buffers/buffer-creation.js buffers/buffer-creation.js type=fast len=10 n=1024: 4580.3 Memory usage: 11,571,200 buffers/buffer-creation.js type=fast len=1024 n=1024: 2780.7 Memory usage: 19,652,608 buffers/buffer-creation.js type=slow len=10 n=1024: 2264.3 Memory usage: 11,571,200 buffers/buffer-creation.js type=slow len=1024 n=1024: 1651.9 Memory usage: 18,628,608
-
- v0.10.4:
-
without jemalloc:
buffers/buffer-creation.js buffers/buffer-creation.js type=fast len=10 n=1024: 3242.3 Memory usage: 11,198,464 buffers/buffer-creation.js type=fast len=1024 n=1024: 1739.0 Memory usage: 99,508,224 buffers/buffer-creation.js type=slow len=10 n=1024: 765.39 Memory usage: 68,055,040 buffers/buffer-creation.js type=slow len=1024 n=1024: 535.79 Memory usage: 207,441,920 -
with jemalloc:
buffers/buffer-creation.js buffers/buffer-creation.js type=fast len=10 n=1024: 3454.7 Memory usage: 11,427,840 buffers/buffer-creation.js type=fast len=1024 n=1024: 1509.1 Memory usage: 28,893,184 buffers/buffer-creation.js type=slow len=10 n=1024: 607.29 Memory usage: 21,639,168 buffers/buffer-creation.js type=slow len=1024 n=1024: 565.65 Memory usage: 57,782,272
-
Time to start linking against jemalloc?
Activity
jbergstroem commentedon Apr 20, 2013
@mscdex Interesting indeed. Did you use LD_PRELOAD to run with jemalloc or patch the build?
mscdex commentedon Apr 20, 2013
I used LD_PRELOAD in this case to make it easier to compare.
jbergstroem commentedon Apr 20, 2013
Just tried an linux x86_64 build and got similar results (vs glibc 2.15). Will test on other architectures (linux x86, smartos, fbsd x86/amd64) shortly.
bnoordhuis commentedon Apr 22, 2013
Have you tried other benchmarks beside buffer-creation? Last time I tried jemalloc it was consistently 2-3% slower than glibc's malloc on x86_64 Linux.
chrisdickinson commentedon Nov 17, 2014
Is this still of interest?
jbergstroem commentedon Nov 18, 2014
I just ran another bench vs jemalloc 3.6.0. Build with clang 3.5.0 and ran ~5 times (if link goes missing: it's pretty much both ways since results vary between each). For anything to happen in this issue, I foresee a lot of work.
http://fiddle.jshell.net/zkvLaqfh/show/
bnoordhuis commentedon Nov 18, 2014
I wonder if our benchmarks simply aren't that great; I wouldn't expect that kind of variance.
Aside, one issue with having a custom allocator is that it may not play well with add-ons. Imagine what would happen when memory allocated with jemalloc is passed to an add-on that frees it with the system allocator (or vice versa.) It's more of a general caution because I don't believe we have APIs like that now.
jasnell commentedon May 26, 2015
@mscdex .. is this still relevant?
jbergstroem commentedon May 26, 2015
I guess we could revisit but I don't think the results would be much different.
jasnell commentedon May 26, 2015
Given that and the lack of any action, I'm inclined to close this. Can reopen and revisit if new information is received.