Added fast paths in std.utf.byUTF

[JackStouffer]

@9il @DmitryOlshansky

[9il]

please benchmarks with combination with previous one PR

[JackStouffer]

Just tested it, still slower and with no noticeable difference in speed.

Hmm, I'm looking at the profile output and I don't see what could be causing the 8x slower speeds.

[9il]

maybe inlining bug?

[JackStouffer]

I don't think so, but I am a novice at assembly. I found LDC's output of the function, but I don't see a call for it anywhere, so I guess it was inlined at every call point

[dnadlinger]

You can also try the LLVM IR output (-output-ll), which you might find easier to read as it is higher-level and (partially) has descriptive names.

[DmitryOlshansky]

Possibly isASCII is not inlined, just use plain old < 0x80

[JackStouffer]

No effect

[JackStouffer]

Ok, I think I've figured it out. byUTF spends time decoding dchars when toUTF8 correctly skips that step with dstrings.

Will post numbers soon.

[JackStouffer]

Well, that did make the UTF string faster, but I forgot that the ascii string isn't using that code path, so no change :/

$ ./test

ASCII w/ old    153 ms, 351 μs, and 1 hnsec
ASCII w/ new    533 ms, 803 μs, and 3 hnsecs
UTF w/ old  1 sec, 333 ms, 845 μs, and 4 hnsecs
UTF w/ old  690 ms, 884 μs, and 6 hnsecs

[JackStouffer]

Regardless of the other PR, these are two good optimizations that IMO should be pulled.

[JackStouffer]

Fixed test errors

[codecov-io]

Current coverage is 88.68% (diff: 100%)

Merging #4642 into master will increase coverage by <.01%

@@             master      #4642   diff @@
==========================================
  Files           121        121          
  Lines         73827      73833     +6   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits          65471      65477     +6   
  Misses         8356       8356          
  Partials          0          0          

Powered by Codecov. Last update 6db08d3...46594d6

[JackStouffer]

Ping

[JackStouffer]

Ping @9il

[wilzbach]

please benchmarks with combination with previous one PR

How about starting to include such benchmarks in a special benchmark folder?
This would make it easier for future improvements & also help to prevent regressions.

I believe @burner is envisioning sth. similar with #2995, but we could still start to collect the benchmark script as (a) it comes "for free" (they are already written) and (b) might help to move forward with a future "full-blown" benchmark suite as we then already have real scripts and know what functions / features are lacking.

Btw runtime has already gone a similar way.

(pinging @qznc as he has written a nice blog post about benchmarking Phobos)

[JackStouffer]

Ping @9il @klickverbot

I think these two optimizations are good to go regardless of the other PR.

[JackStouffer]

@andralex Thanks!