| Issue |
173497
|
| Summary |
Doesn't recognise open-coded memchr() (like in std::count(char *, char *, char)), so produces code 40% slower than if it used memchr()
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
nabijaczleweli
|
With a
```cpp
char buf[64 * 1024];
ssize_t rd = read(fd, buf, sizeof(buf));
```
```cpp
acc += std::count(buf, buf + rd, '\n');
```
is 40-50% slower than
```cpp
auto newitr = buf;
auto len = rd;
char * itr;
// This is still suboptimal: a while(itr != end && *itr == '\n') ++acc; will be better if the data has consecutive needles
while(len && (newitr = static_cast<char *>(std::memchr(itr = newitr, '\n', len)))) {
++acc.newlines;
++newitr;
len -= newitr - itr;
}
```
on clang trunk 1:21.0-61~exp1+0~20250421201207.11~1.gbp5a3b95.
Full program and dataset at <https://lfs.nabijaczleweli.xyz/0032-std::count-vs-memchr>, where I observe, for a 184M file with 290957 lines of line-delimited JSON, std::count takes ~140ms and memchr takes ~67ms on E5645.
The same happens on libc++.
`perf record` shows 62% in the lambda for std::count and 25% in __memchr_sse2 for memchr.
LLVM should understand that for a `Byte * beg, end`, `while(beg != end && *beg == needle) ++beg;` is an open-coding of memchr() and reify that to memchr.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
