You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In private conversations with @tumberger we discussed 2 ways of measuring memory usage:
in-language memory benchmarks: this would require most likely require usage of jemalloc, which means we need to depend on libc directly.
external tools: we could also use /usr/bin/time or something like valgrind.
If we decide on 2), the logic between the test runner<>benchmarks would have to be separated, since in the current runner we are doing other tasks like writing to CSV, etc. which means we may not get the most accurate results.
The text was updated successfully, but these errors were encountered:
We will probably need to go with the second option so that we can use the same tooling across all frameworks. Hence, we will need separate runners per phase.
In private conversations with @tumberger we discussed 2 ways of measuring memory usage:
in-language memory benchmarks: this would require most likely require usage of jemalloc, which means we need to depend on libc directly.
external tools: we could also use
/usr/bin/time
or something likevalgrind
.If we decide on 2), the logic between the test runner<>benchmarks would have to be separated, since in the current runner we are doing other tasks like writing to CSV, etc. which means we may not get the most accurate results.
The text was updated successfully, but these errors were encountered: