[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: 32194@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 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.