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

[Renato]

On Monday, 15 January 2024 at 01:10:14 UTC, Sergey wrote:
> On Sunday, 14 January 2024 at 17:11:27 UTC, Renato wrote:
>> If anyone can find any flaw in my methodology or optmise my 
>> code so that it can still get a couple of times faster, 
>> approaching Rust's performance, I would greatly appreciate 
>> that! But for now, my understanding is that the most promising 
>> way to get there would be to write D in `betterC` style?!
>
> I've added port from Rust in the PR comment. Can you please 
> check this solution?
> Most probably it need to be optimized with profiler. Just 
> interesting how close-enough port will work.

As discussed on GitHub, the line-by-line port of the Rust code is 
5x slower than [my latest solution using 
int128](https://github.com/renatoathaydes/prechelt-phone-number-encoding/blob/0cbfd41a072718bfb0c0d0af8bb7266471e7e94c/src/d/src/dencoder.d), which is itself 3 to 4x slower than the Rust implementation (at around the same order of magnitude as algorithm-equivalent Java and Common Lisp implementations, D is perhaps 15% faster).

I did the best I could to make D run faster, but we hit a limit 
that's a bit hard to get past now. Happy to be given suggestions 
(see profiling information in previous messages), but I've run 
out of ideas myself.