D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 19617 - [REG 2.085a] Much slower GC compared to 2.084
Summary: [REG 2.085a] Much slower GC compared to 2.084
Status: RESOLVED INVALID
Alias: None
Product: D
Classification: Unclassified
Component: druntime (show other issues)
Version: D2
Hardware: All All
: P1 regression
Assignee: No Owner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-26 11:03 UTC by basile-z
Modified: 2019-03-13 09:18 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description basile-z 2019-01-26 11:03:57 UTC
I wanted to test something and took this code from the dlang tour:

---
// Hey come on, just get the whole army!
import std.algorithm : canFind, map,
  filter, sort, uniq, joiner, chunkBy, splitter;
import std.array : array, empty;
import std.range : zip;
import std.stdio : writeln;
import std.string : format;
import std.datetime.stopwatch;

void main()
{
    StopWatch sw;
    sw.start;
    string text = q{This tour will give you an
overview of this powerful and expressive systems
programming language which compiles directly
to efficient, *native* machine code.};

    alias pred = c => canFind(" ,.\n", c);
    auto words = text.splitter!pred
      .filter!(a => !a.empty);
    auto wordCharCounts = words
      .map!"a.count";

    zip(wordCharCounts, words)
      .array()
      .sort()
      .uniq()
      .chunkBy!(a => a[0])
      .map!(chunk => format("%d -> %s",
          chunk[0],
          chunk[1]
            .map!(a => a[1])
            .joiner(", ")))
      .joiner("\n")
      .writeln();
      writeln(sw.peek);
}
---

- dmd args : -O -release -inline -boundscheck=off
- exe generated with DMD 2.084 takes on average 110 µs
- the one with DMD ~master (aa0c2062499419cc933f9bbf94cf88ec3244e2f9) takes on average 145 µs.

Note that the same difference is observed without any DMD arg at all.
Comment 1 basile-z 2019-01-27 09:22:30 UTC
So it's likely the GC that's slower not the cde generated. If you add a GC.dsiable; before start the stopwatch the timing are similar using 2.084 and ~master.
Comment 2 Rainer Schuetze 2019-01-28 22:45:09 UTC
There is little difference on my system between 2.083 and git HEAD, maybe 110 µs and 120 µs, respectively. These number are way too small for a benchmark as every unrelated detail can make a big difference. If I make the text longer so that the time is a about 1ms (still very small), the absolute difference is about the same if at all noticable in the noise.

The most likely related change in the GC is that intermediate allocation sizes are now supported, too (these were power of 2 only so far). This can lead to less memory being used for the same allocations (up to about 30%), but it also changes when collections are run. Appending to arrays might also reallocate a bit more often.
Comment 3 basile-z 2019-01-31 11:31:04 UTC
I didn't want to blame you or discredit your recent work on the GC Rainer. I'll try bigger benchmark and close the issue if it appears that I have over-reacted to a micro benchmark.
Comment 4 Rainer Schuetze 2019-02-01 07:31:14 UTC
No problem. I also noticed a couple of changes in the druntime benchmarks, some for the better, some for the worse. Those mostly boiled down to how many garbage collections are run which changes if memory is used differently.