On Saturday, 13 January 2024 at 17:00:58 UTC, Anonymouse wrote:
On Saturday, 13 January 2024 at 12:55:27 UTC, Renato wrote:
[...]
Not a great profiling experience :). Anyone has a better
suggestion to "parse" the trace file?
As a drive-by suggestion and I hope it doesn't derail anything,
but if you have the opportunity to run it on linux, have you
tried profiling with callgrind instead, with {Q,K}Cachegrind to
visualise things? Your repositories probably have them.
(callgrind is a part of valgrind.)
The wiki only mentions callgrind in passing, but it has worked
well for me. [(example)](https://i.imgur.com/WWZAwy3.png)
Thanks for the suggestion, this looks promising as I do have a
Linux laptop (just not my main one).
I will have to try it... I thought that `BigInt` was to blame for
the slowness (from what I could read from the trace logs), but
after replacing that with basically a byte array key (see [commit
here](https://github.com/renatoathaydes/prechelt-phone-number-encoding/commit/0e9025b9aacdcfef5a2649be4cc82b9bc607fd6c)) it barely improved. It's still much slower than Common Lisp and very, very far from Java and Rust.
