Follow-up Comment #9, bug #67509 (group groff): At 2025-09-18T20:55:19-0400, G. Branden Robinson wrote: > Follow-up Comment #8, bug #67509 (group groff): > At 2025-09-18T20:16:23-0400, Deri James wrote: >> Follow-up Comment #7, bug #67509 (group groff): >> >> On Thursday, 18 September 2025 23:16:25 BST G. Branden Robinson wrote: >>> Follow-up Comment #6, bug #67509 (group groff): >>> >>> At 2025-09-18T17:40:00-0400, Deri James wrote: >>>> I thing the only bit left is '.strhex'. So the only thing >>>> preventing branch deletion is waiting for "I must do something >>>> about that" when I told you about the significant slow down in >>>> specific workloads since the introduction of the looping lookup. >>> >>> Right. Is that reproducible with the master branch today? If so, >>> with what input document? >>> >>> A reproducer that is easy for me to throw at the code would help >>> immensely. >> >> Hi Branden, >> >> The instructions for testing were here:- >> >> <https://lists.gnu.org/archive/html/groff/2024-12/msg00168.html> >> >> Just grab the file referred to, DON'T do the git checkout, DON'T >> apply the patch, DO run:- >> >> time (./test-pdfmom --roff -Tpdf -man -petk LMB.prep > dj.pdf ) > > I have no "test-pdfmom", so I simply used my installed version of > "pdfmom"... > > $ type -p pdfmom > /home/branden/groff-HEAD/bin/pdfmom > $ pdfmom --version > GNU pdfmom (groff) version 1.23.0.3971-05036 > >> It runs in about 02:45 on my rig (this includes my "speedup" code, if >> you want to discover the state it was in after you inserted your code >> follow the instructions in the quoted list message - or take my word >> it was over 10 mins). This compares to 16 secs before your code was >> added. > > I found 'em. Your rig is beefier than mine--took me a bit longer! >
> real 6m44.709s
> user 7m16.121s
> sys 0m1.819s
So, let's do the time warp (again?).
$ git checkout 7705cbd5f8fb4b666954edcbbc810feff8020cbc
$ git show | head -n 5
commit 7705cbd5f8fb4b666954edcbbc810feff8020cbc
Author: G. Branden Robinson <g.branden.robin...@gmail.com>
Date: Mon Mar 4 04:24:34 2024 -0600
doc/GMPfront.t.in: Resync with an.tmac's `MR`.
$ noisily env CORES=10 make-groff-fast
$ make -C build install
$ time (pdfmom --roff -Tpdf -man -petk LMB.prep > dj-faster.pdf )
[warnings snipped]
real 0m36.087s
user 0m45.960s
sys 0m0.717s
Oy, vey. Yes, that's way, way better.
...but wait. This is odd.
$ git checkout cd9fde325fd889f673f9603b43e1204b1fde42fc
$ git show | head -n 5
commit cd9fde325fd889f673f9603b43e1204b1fde42fc
Author: G. Branden Robinson <g.branden.robin...@gmail.com>
Date: Mon Mar 4 05:24:40 2024 -0600
[pdf]: Implement linear bookmark tag search.
$ noisily env CORES=10 make-groff-fast
$ make -C build install
$ time (pdfmom --roff -Tpdf -man -petk LMB.prep > dj-faster.pdf )
[warnings snipped]
real 0m36.947s
user 0m47.109s
sys 0m0.920s
-verbatim-
Something fishy is going on here. I can replicate HEAD's miserable
performance, but my performance-trashing linear search
implementation...didn't trash performance?!
Huh. I vaguely remember you undid my linear search, then put it back,
or something like that. Maybe something got damaged in the process.
Looks like I have a bisection in my future with potential 6+-minute
waits between stages. Fun! :-|
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67509>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
