GLib · GitLab (original) (raw)

GitLab

Blame Permalink

Oct 15, 2024
e3e936f7
gdatainputstream: Use memchr() for the multi-stop-char case too · e3e936f7
Philip Withnall authored Oct 15, 2024
This is a follow up to commit e7e5ddd2. oss-fuzz found a case where
performance was pathologically bad with a long stop_chars string.
Since our inner loop in that case was iterating over stop_chars and
comparing each of them to buffer[i], we can use memchr() the
opposite way round to in commit e7e5ddd2 to speed that up, using
buffer[i] as the needle in a stop_chars haystack.
From some brief testing, this doesn’t impact on the performance of a
more normal use case of having a short (<10 bytes long) stop_chars. I
was slightly concerned that the function call overhead of calling out to
memchr() would have an impact there, but apparently not.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
oss-fuzz#372994443
e3e936f7
gdatainputstream: Use memchr() for the multi-stop-char case too
Philip Withnall authored Oct 15, 2024
This is a follow up to commit e7e5ddd2. oss-fuzz found a case where
performance was pathologically bad with a long stop_chars string.
Since our inner loop in that case was iterating over stop_chars and
comparing each of them to buffer[i], we can use memchr() the
opposite way round to in commit e7e5ddd2 to speed that up, using
buffer[i] as the needle in a stop_chars haystack.
From some brief testing, this doesn’t impact on the performance of a
more normal use case of having a short (<10 bytes long) stop_chars. I
was slightly concerned that the function call overhead of calling out to
memchr() would have an impact there, but apparently not.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
oss-fuzz#372994443