bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32194: [PATCH] Use Gnulib regex for lib-src


From: Eli Zaretskii
Subject: bug#32194: [PATCH] Use Gnulib regex for lib-src
Date: Sun, 05 Aug 2018 20:58:41 +0300

> Cc: address@hidden
> From: Paul Eggert <address@hidden>
> Date: Sat, 4 Aug 2018 16:34:33 -0700
> 
> > 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.

Thanks.

> >>> 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.

No, I was talking about src/regex.c, not Gnulib regex.

But it turns out I've misread the patch: you are actually leaving the
!WIDE_CHAR_SUPPORT code intact, since Emacs needs that on all
platforms.  So please ignore that comment.

> > 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.

10% doesn't sound significant to me, thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]