D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 9477 - String (and array) comparisons are needlessly very slow
Summary: String (and array) comparisons are needlessly very slow
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: All All
: P2 enhancement
Assignee: No Owner
URL:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2013-02-08 01:18 UTC by Vladimir Panteleev
Modified: 2014-02-15 07:59 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Vladimir Panteleev 2013-02-08 01:18:10 UTC
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 2 github-bugzilla 2013-03-31 01:02:10 UTC
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 bearophile_hugs 2013-04-01 14:55:13 UTC
See also Issue 6658
Comment 4 Vladimir Panteleev 2014-02-15 07:44:19 UTC
@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 yebblies 2014-02-15 07:56:04 UTC
(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 Andrej Mitrovic 2014-02-15 07:59:53 UTC
(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 github-bugzilla@puremagic.com's comments) is located in some older tagged branch.