Eli Zaretskii writes: >> From: Kévin Le Gouguec >> Cc: 69555@debbugs.gnu.org, rahguzar@zohomail.eu >> Date: Tue, 05 Mar 2024 20:22:52 +0100 >> >> Eli Zaretskii writes: >> >> > Also, please time the code on some substantially large body of text, >> > with and without shr-fill-text, and compare that with the current >> > version. I think performance is an important aspect of any change in >> > this area. >> >> Can do; would "(elisp) Profiling" be the starting point? > > I think benchmark-run is a better starting point. > >> (Also wondering if we have any "standard" or preferred HTML documents or >> websites to throw at shr.el for benchmarking purposes; if not, I guess >> I'll peruse 🤔) > > Actually, something with a lot of text in large paragraphs, sometimes > indented, would be better. Those Wikipedia pages are basically long > lists, but there's not much opportunity there to perform filling and > indentation of large amounts of text, which is what is sought here. > Here's one possible candidate: > > https://debbugs.gnu.org/Developer.html Thanks for the pointers. Attaching the over-engineered scripts I built from that, which with 1000 REPETITIONS yield: 2024-03-05; 33976ecf244; 30.0.50; master shr-fill-text=nil ( 3.013 23 0.313) 2024-03-04; b06916cb218; 30.0.50; shr-blockquote shr-fill-text=nil ( 3.121 24 0.328) 2024-03-05; 33976ecf244; 30.0.50; master shr-fill-text=t (32.331 65 0.904) 2024-03-04; b06916cb218; 30.0.50; shr-blockquote shr-fill-text=t (32.045 65 0.902) I can bump up REPETITIONS if that would help; sending the scripts & results as-is before hitting the hay since I figure they might have some glaring methodology issues, or there is more information I might not have thought of reporting. If not, the tentative conclusion would be "shr-fill-text nil gets 4% slower; shr-fill-text t is none the worse for wear; nil still runs circles around t"?