Bug 9477 – String (and array) comparisons are needlessly very slow

Status
RESOLVED
Resolution
FIXED
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-02-08T01:18:00Z
Last change time
2014-02-15T07:59:53Z
Keywords
performance
Assigned to
nobody
Creator
dlang-bugzilla

Comments

Comment #0 by dlang-bugzilla — 2013-02-08T01:18:10Z
While profiling one of my programs, I've noticed a performance issue in an area that I wouldn't expect to be slow: string comparisons. It looks like array comparisons go through the rather convoluted TypeInfo equality code, which contains a few indirect calls and calls to runtime code. It can be inlined/optimized to a length comparison and a memcmp call. If the length is known (static arrays), the length check can be skipped, and for short arrays the comparison can even be inlined. Bearophile previously reported this problem for static arrays in issue 6658. I should note that a slice copy currently compiles to a memcpy call.
Comment #1 by bugzilla — 2013-03-31T00:59:25Z
Comment #2 by github-bugzilla — 2013-03-31T01:02:10Z
Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c984175cf25dfa17b3956e8e33ff83547fa56b0a Optimize simple array comparison (Issue 9477) https://github.com/D-Programming-Language/dmd/commit/8b9d88d19fe4bb239209c004230fd5ac271436c3 Merge pull request #1766 from CyberShadow/fix9477 Optimize simple array comparisons (Issue 9477)
Comment #3 by bearophile_hugs — 2013-04-01T14:55:13Z
See also Issue 6658
Comment #4 by dlang-bugzilla — 2014-02-15T07:44:19Z
@Daniel: I thought we need to close bugs that were not fixed in the current development iteration as WORKSFORME? Otherwise they'll end up in this iteration's changelog.
Comment #5 by yebblies — 2014-02-15T07:56:04Z
(In reply to comment #4) > @Daniel: I thought we need to close bugs that were not fixed in the current > development iteration as WORKSFORME? Otherwise they'll end up in this > iteration's changelog. No, WORKSFORME is for bugs with an unknown fix, such as ones that are probably a duplicate of another bug. This should be in the changelog, and better in the wrong version than not at all. Basically, keeping the bug tracker correct should be preferred over twisting it to fix the changelog, as this is the real history. https://d.puremagic.com/issues/page.cgi?id=fields.html#status
Comment #6 by andrej.mitrovich — 2014-02-15T07:59:53Z
(In reply to comment #5) > (In reply to comment #4) > > @Daniel: I thought we need to close bugs that were not fixed in the current > > development iteration as WORKSFORME? Otherwise they'll end up in this > > iteration's changelog. > > No, WORKSFORME is for bugs with an unknown fix, such as ones that are probably > a duplicate of another bug. This should be in the changelog, and better in the > wrong version than not at all. It's not that hard to strip this out of the changelog by hand. It would be good if it was automatic, e.g. if the changelog tool would go through all bugzilla issues and then search whether a commit that fixed the issue (it would have to grep [email protected]'s comments) is located in some older tagged branch.