Follow-up Comment #8, bug #67509 (group groff): Hi Deri,
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 >>> I was hoping, and you have mentioned it in passing, using c++ maps >>> in groff, would result in a new .map/.lookup feature for groff >>> which would have many user applications such as possibly indexing, >>> as well as in pdf.tmac. >> >> I'd prefer to avoid adding major new features at this point in this >> release cycle, but if there's a slowdown that is unbearable, we'll >> have to resolve it somehow. > > Although this job (on bleeding edge) has a 10x slowdown, it is very > much dependent on the size of the lookup table and the number of > lookups which fail, this job is not typical, although in the noughties > I was doing millions of pages through groff (for a UK bank) and being > paid £25 per 1000 pages (I paid the sales and helpdesk (who worked for > a software company) in a percentage). The reason I got the job is > because groff was lightening compared to the commercial report writing > software running on windows, which required multiple servers and > licenses. I would not be happy at a slowdown if I hadn't retired. I don't blame you. > So I think we can live with it for this release, and you can take the > flak if someone else is using groff for monster jobs. Theoretically, that's what release candidates are for. But I suspect I won't get any feedback on performance from the public until after release, and it sounds I'm taking a risk of some negativity. >> Hmm, well, any printable character is legal in a string identifier >> except the escape character, which is configurable. >> >> So you might do something underhanded like this. >> >> >> .\" Define a new key string. >> .eo >> .ds pdf*key*\[u1234]\[u2345]*whatever value-\[u1234]\[u2345] >> .ec >> . >> .\" ...much later... >> . >> .\" Look it up. >> .eo >> .als pdf*bookmark-content pdf*key*\[u1234]\[u2345]*whatever >> .ec >> . >> .\" Use it. >> \X'pdf:bookmark \*[pdf*bookmark-content] > > I think I have v. similar code in one of my stashes. I know I hit a > wall, can't remember, it may have been before we added \A'' protection > on loops using parameters. I'm going to have re-spin myself up on this stuff. I think I want to roll my working copy back to before I introduced the O(n) search and measure the performance on this LMB.prep document. I fully expect to verify your claims, and when I do I'll file a new ticket about the matter. Can you think of anything besides a review/update of our `asciify` request documentation that keeps its refactoring/completion from being fit for gropdf's (and the PDFfy bits of mom(7)'s) purposes? Regards, Branden _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?67509> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
