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

[Renato]

>> Looks like we lost out to Rust for larger inputs. :-D  
>> Probably due to environmental factors (and the fact that 
>> std.stdio is slow).  I re-ran it again and got this:
>>
>> ===> ./rust
>> ./rust,22896640,30
>> ./rust,22896640,131
>> ./rust,22896640,511
>> ./rust,22896640,983
>> ./rust,8785920,3102
>> ./rust,8785920,9912
>> ===> src/d/dencoder
>> src/d/dencoder,1066799104,36
>> src/d/dencoder,1066799104,71
>> src/d/dencoder,1066799104,197
>> src/d/dencoder,1066799104,355
>> src/d/dencoder,1035292672,3441
>> src/d/dencoder,1035292672,9471
>>

I forgot to mention: the Java version is using a Trie... and it 
consistently beats the Rust numeric algorithm (which means it's 
still faster than your D solution), but the Java version that's 
equivalent to Rust's implementation is around 3x slower... i.e. 
it runs at about the same speed as my current fastest numeric 
algorithm in D as well.

This is what I would like to be discussing in this thread: why is 
D running at Java speeds and not at D speeds when using the same 
algorithm? I know there's small differences in the 
implementations, they are different languages after all, but not 
enough IMO to justify anything like 3x difference from Rust.

If you really want to show to me that D is as fast as Rust, 
please spend time on my solution (because that's a direct 
comparison algorithmically to the Rust implementation) and remove 
any unnecessary overhead from it (without changing the overall 
algorithm , of course - unless that's to make it closer to the 
Rust implementation).


>
> Do you know why the whole thread seems to have disappeared?? 
> There's a lot of good stuff in the thread, it would be a huge 
> shame to lose all that!

Nevermind, looks like I was unable to open any other answers in 
this thread while writing my own answer!?