|
From: | Paul Eggert |
Subject: | bug#32194: [PATCH] Use Gnulib regex for lib-src |
Date: | Sat, 4 Aug 2018 16:34:33 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
Eli Zaretskii wrote:
The idea is that the system-supplied regex library is also GNU regex, but one tuned better to the specific platform. The configure script could check whether that library is up to speed, before using it. Obviously, not a terribly important issue, but I've seen projects that do this.
I doubt whether any platform has a system-supplied regex library compatible with the glibc API and performing significantly better. The glibc code is hairy and was written by an expert and its behavior would be hard to replicate. In the unlikely event that there is such a platform and it requires unusual flags, that platform's builder can simply configure with the appropriate CFLAGS, LDLIBS, etc. We needn't worry about this unlikely event.
I'd only ask that the renaming be done as a separate commit before the rest of the changes in those two files, so that all the changes in src/regex.[ch] will be after the rename, as that will make future forensics easier.
OK, will do.
P.S. Is it true that this version will no longer support a build with WIDE_CHAR_SUPPORT undefined, i.e. those which have only the C locale?I don't see any issues with such a build. What sort of problem do you have in mind?AFAIU, you suggest removing the !WIDE_CHAR_SUPPORT code, but we previously supported platforms that don't have all the prerequisites for using that code.
If I understand you correctly, I doubt whether such platforms survive now. If they do we can add Gnulib-based substitutes for the missing prerequisites. I already did that in Bug#32194#5; you suggested in Bug#32194#8 point (3) that we not bother with it, though, and this seemed like good idea so that's what in the current proposal. If the idea doesn't work it will be easy to go back to the approach in Bug#32194#5 (as I recall it's a simple change to admin/merge-gnulib followed by turning the crank).
(malloc, realloc, free): Do not redefine. Adjust all callers to use xmalloc, xrealloc, xfree instead.Is this wise? xmalloc etc. are tuned to allocate Lisp data and aligned objects, something that isn't necessarily needed in regex library. Why not use the normal memory allocation routines?
src/regex.c is already using Lisp allocation when compiled as part of Emacs, so this is just code simplification, not a real change. The Emacs regex code needs to use xmalloc to do the right thing with memory exhaustion and to do memory profiling.
we should compare the performance of etags before and after the switch, just to be sure we aren't going to suffer a performance penalty.
I expect there to be a performance penalty but it's no big deal. On my old Fedora 28 x86-64 platform with 'make TAGS CFLAGS='-O2 -march=native"' in the Emacs src directory, user+system time grows from 0.55 to 0.59 seconds, about a 10% slowdown. It grows about 10% more, to 0.64 seconds, if I use the system-installed regex library instead of the Gnulib-supplied one. I don't view an extra tenth of a second as a glitch big enough to be worth investigating.
[Prev in Thread] | Current Thread | [Next in Thread] |