bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH 1/4] maint.mk: speed up po_check


From: Eric Blake
Subject: Re: [PATCH 1/4] maint.mk: speed up po_check
Date: Fri, 29 Jul 2016 15:14:01 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 07/26/2016 08:28 AM, Ján Tomko wrote:
> There is some logic in sc_po_check that skips files based on their
> names, or existence of files with derived names.
> 
> Rewrite it in perl instead of shell to make the check faster.
> ---
>  ChangeLog    |  9 +++++++++
>  top/maint.mk | 35 ++++++++++++++++++++---------------
>  2 files changed, 29 insertions(+), 15 deletions(-)
> 

Do you have sample timing differences for this patch; and how many files
were run on your testing?  I'm guessing that you used libvirt as your
testbed, which has about 885 .[ch] files listed by $(VC_LIST_EXCEPT)...

> @@ -1132,21 +1150,8 @@ sc_po_check:
>       @if test -f $(po_file); then                                    \
>         grep -E -v '^(#|$$)' $(po_file)                               \
>           | grep -v '^src/false\.c$$' | sort > address@hidden;                
>         \
> -       files=;                                                       \
> -       for file in $$($(VC_LIST_EXCEPT)) $(generated_files); do      \
> -         test -r $$file || continue;                                 \
> -         case $$file in                                              \
> -           *.m4|*.mk) continue ;;                                    \
> -           *.?|*.??) ;;                                              \
> -           *) continue;;                                             \
> -         esac;                                                       \
> -         case $$file in                                              \
> -         *.[ch])                                                     \

...so while a shell loop executed 885+ times is not necessarily the
fastest compared to a single perl process, the real savings...

> -           base=`expr " $$file" : ' \(.*\)\..'`;                     \

...comes from avoiding 885 forks of expr,

> -           { test -f $$base.l || test -f $$base.y; } && continue;;   \
> -         esac;                                                       \
> -         files="$$files $$file";                                     \

as well as avoiding any inefficient shell allocation schemes that cost
quadratic rather than amortized linear time when building up a list of
885 words one append at a time.

> -       done;                                                         \
> +       files=$$(perl $(perl_translatable_files_list_)                \
> +         $$($(VC_LIST_EXCEPT)) $(generated_files)) ;                 \

The patch makes sense to me, but I'd rather get Jim's opinion as
original author if it is okay to use perl like this.  At least we are
guaranteed that 'make syntax-check' has perl available, since it is a
developer tool, and perl is already available for the developer's use of
automake.

>         grep -E -l '$(_gl_translatable_string_re)' $$files            \
>           | $(SED) 's|^$(_dot_escaped_srcdir)/||' | sort -u > address@hidden; 
> \
>         diff -u -L $(po_file) -L $(po_file) address@hidden address@hidden     
>                 \
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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