Help optimize D solution to phone encoding problem: extremely slow performace.

[Renato]

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.