[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#55636: 27.2; etags performance fix when working with very big TAGS f
From: |
VAN VLIERBERGHE Stef |
Subject: |
bug#55636: 27.2; etags performance fix when working with very big TAGS files |
Date: |
Thu, 26 May 2022 13:50:32 +0000 |
You are right, I tried an strace and only see the tags files being read.
I also can't get the 10 sec behaviour any more, maybe some other factors were
involved that made the emacs tag file processing slow.
What I did at the time to analyze was to enable debugger on Ctrl-G and then I
notices emacs was busy here :
Debugger entered--Lisp error: (quit)
expand-file-name(#("/cm/ot/TOOL/GTK!27.0.0.1/build_G!27.IP.L7/sources/..." 0
88 (charset iso-8859-1)))
mapcar(expand-file-name
(#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..."
0 81 (charset iso-8859-1))
#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 80 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..."
0 82 (charset iso-8859-1))
#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..."
0 82 (charset iso-8859-1))
#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..."
0 82 (charset iso-8859-1))
#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..."
0 82 (charset iso-8859-1))
#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..."
0 82 (charset iso-8859-1))
#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..."
0 83 (charset iso-8859-1))
#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 83 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..."
0 82 (charset iso-8859-1))
#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..."
0 82 (charset iso-8859-1))
#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..."
0 82 (charset iso-8859-1))
#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..."
0 82 (charset iso-8859-1))
#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..."
0 82 (charset iso-8859-1))
#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..."
0 82 (charset iso-8859-1))
#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..."
0 82 (charset iso-8859-1))
#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..."
0 82 (charset iso-8859-1))
#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..."
0 82 (charset iso-8859-1))
#("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82 (charset
iso-8859-1)) #("/cm/build9/cm/ot/TOOL/G!27.IP.L7/build_G!27.IP.L7/..." 0 82
(charset iso-8859-1)) ...))
tags-table-including("/tmp/vvl.Tstatus.out" t)
visit-tags-table-buffer()
find-tag-noselect("-tv_summary.adb" nil nil)
>From that I concluded the expand-file-name was the cause.
Hope this helps and all the best,
Stef
-----Original Message-----
From: Eli Zaretskii <eliz@gnu.org>
Sent: 26 May 2022 07:07
To: VAN VLIERBERGHE Stef <stef.van-vlierberghe@eurocontrol.int>
Cc: DE BACKER Jurgen (EXT) <jurgen.de-backer.ext@eurocontrol.int>;
55636@debbugs.gnu.org; WAROQUIERS Philippe <philippe.waroquiers@eurocontrol.int>
Subject: Re: bug#55636: 27.2; etags performance fix when working with very big
TAGS files
> From: VAN VLIERBERGHE Stef <stef.van-vlierberghe@eurocontrol.int>
> CC: "55636@debbugs.gnu.org" <55636@debbugs.gnu.org>, WAROQUIERS Philippe
> <philippe.waroquiers@eurocontrol.int>
> Date: Wed, 25 May 2022 20:42:16 +0000
>
> For us the 10 sec is reduced to below 1 sec, loading the tags file is no
> longer noticed after this change.
>
> I assume the reason is a huge amount of files all accessed over NFS, and
> expand-file-name does a lot of system calls that translate into network
> packets.
Actually, expand-file-name is a purely syntactical function that is supposed
not to hit the filesystem at all, at l;east on Posix systems.
So I wonder why it seems to happen in your case. Any chances that you could
show a trace of system calls for those 10 sec?
Of course, making a simple change that you suggested is a no-brainer, so we
might as well do it without further ado, but I'm just curious and think maybe
we will learn something useful if we dig a bit deeper into your use case.
> An alternative approach is to add some switch that allows a customization
> that simply never calls the expand-file-name, we generate tags files that
> already contain absolute paths so don't need any of this logic and disabling
> it would also be ok for us.
That'd be less clean, I think: if we can do something automatically, it's
better to do that instead of placing the burden on the user.
Again, I'm not asking these questions because I see some problem in your
proposed change. If we arrive at the conclusion that there's no reason to
investigate more, we can just install that change, as it cannot possibly hurt.
Thanks.
____
This message and any files transmitted with it are legally privileged and
intended for the sole use of the individual(s) or entity to whom they are
addressed. If you are not the intended recipient, please notify the sender by
reply and delete the message and any attachments from your system. Any
unauthorised use or disclosure of the content of this message is strictly
prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on
the part of EUROCONTROL, unless it is confirmed by appropriately signed hard
copy.
Any views expressed in this message are those of the sender.
- bug#55636: 27.2; etags performance fix when working with very big TAGS files, Jurgen De Backer, 2022/05/25
- bug#55636: 27.2; etags performance fix when working with very big TAGS files, Eli Zaretskii, 2022/05/25
- bug#55636: 27.2; etags performance fix when working with very big TAGS files, VAN VLIERBERGHE Stef, 2022/05/25
- bug#55636: 27.2; etags performance fix when working with very big TAGS files, Eli Zaretskii, 2022/05/26
- bug#55636: 27.2; etags performance fix when working with very big TAGS files,
VAN VLIERBERGHE Stef <=
- bug#55636: 27.2; etags performance fix when working with very big TAGS files, WAROQUIERS Philippe, 2022/05/26
- bug#55636: 27.2; etags performance fix when working with very big TAGS files, Eli Zaretskii, 2022/05/26
- bug#55636: 27.2; etags performance fix when working with very big TAGS files, WAROQUIERS Philippe, 2022/05/26
- bug#55636: 27.2; etags performance fix when working with very big TAGS files, Eli Zaretskii, 2022/05/26
- bug#55636: 27.2; etags performance fix when working with very big TAGS files, WAROQUIERS Philippe, 2022/05/26