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 #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.