On Sat, Aug 10, 2019 at 12:57 AM René Scharfe <l.s.r@xxxxxx> wrote: > > Am 10.08.19 um 05:05 schrieb Carlo Arenas: > > in macOS (obviously testing without NED) the following is the output > > of (a hacked version) of p7801 for maint (against chromium's > > repository), with René's patch on top > > Do you mean p7820? And what did you change? Looking at the results you > removed basic and extended from the list of regex engines, right? correct, that was a weird typo there; apologize for the confusion. you were correct about my changes; ironically, I didn't spell those changes out to avoid confusion. > Ugh, cloning https://chromium.googlesource.com/chromium/src.git sends > more than 16GB across the wire. Is that even the right repository? noticed it was mentioned before by people[1] doing performance testing on grep specifically and thought it was better than try to come with another one, the linux kernel wouldn't work in macOS because it breaks "run" as it fails to checkout in a case insensitive filesystem. > Not > sure if my machine can keep the relevant parts cached while grepping -- > I/O times could drown out any difference due to context allocation and > memory allocator choice. Let's see... ;), try setting /proc/sys/vm/swappiness to 0 or get more RAM > I don't understand why my performance is lower by factor 2.5 than yours > for all perl regex tests except 7820.15 (your 7820.4), where my system > is two times faster. Debian Testing, GCC 9.1.0, i5-9600K, 16GB RAM. interesting; did you also see at most 100% of one CPU being used? yours seem to be faster than mine so this might be representative of single threaded performance. > Anyway, nedmalloc is slower across the board, but the impact of my > patch is in the noise. Right? yes, and there is a lot of noise. Carlo [1] https://public-inbox.org/git/e72330c6747218545cce1b6b1edfd1e448141a8f.1563570204.git.matheus.bernardino@xxxxxx/
