tpl: Add findRE template func

[digitalcraftsman]

No description provided.

[bep]

What is the performance implications of adding this to a medium sized Hugo site?

[digitalcraftsman]

How do you define medium sized? And the more complex the regexp is the longer it takes. Can you suggest a website for a benchmark with a usecase for a regexp?

[bep]

With the regexp in the example. Would be valuable to see what adding that to the single template on a couple of hundred pages blog adds in time.

[digitalcraftsman]

What do you think if I add the scrollspy example from the docs into the templates for the Hugo pages? Hugo's docs consist of around generated 180 pages.

[bep]

Sure, and you don't have to use the result, just invoke the regexp for every page.

[digitalcraftsman]

The setup: I copied the content of a file from the docs in the default archetype. Next, I wrote a small bash script that generates 400 new content files (is this medium sized?). Finally, I build the site. The benchmark of course does only include the build time of the website not the generation of the content files.

This are the results without regexp:

time ./hugo -s docs

Started building site
0 draft content
0 future content
573 pages created
0 non-page files copied
0 paginator pages created
56 tags created
0 groups created
in 4837 ms
./hugo -s docs  14,46s user 0,42s system 303% cpu 4,901 total

and with the complete scrollspy regexp:

time ./hugo -s docs

Started building site
0 draft content
0 future content
573 pages created
0 non-page files copied
0 paginator pages created
0 groups created
56 tags created
in 4880 ms
./hugo -s docs  14,44s user 0,45s system 301% cpu 4,945 total

As you can see the difference if marginal with such a simple regexp.

[moorereason]

@digitalcraftsman,
I'm curious what the difference would be if you used the existing regexpCache used by replaceRE.

[digitalcraftsman]

Thanks for pointing me to the reCache. I tested it a couple of times and got on average the following result:

Started building site
0 draft content
0 future content
573 pages created
0 non-page files copied
0 paginator pages created
0 groups created
56 tags created
in 4948 ms
./hugo -s docs  14,31s user 0,48s system 295% cpu 5,015 total

Under the line a good improvement of 40ms .

[bep]

Do the 400 content files you generated have matches for your regexp?

[digitalcraftsman]

Yes they have. The default archetype contaited content with multiple level-two headers. Therefore, each generated page triggered the regexp with multiple matches.

I saw you already merged the commit in 5bfe16e. Can this pull request be closed?

[bep]

Oops, I pushed that by mistake, but with those numbers it looks solid. I was a little bit afraid that people would shoot themselves in the feet and get a slow-down.

[digitalcraftsman]

Should we add a note the docs that informs users about this potential bottleneck

[moorereason]

People that are using regexp should know what they're getting into. Let's wait and see how it unfolds. If we start getting a bunch of people confused about why their builds are slow, we can consider updating the docs.

Although, I don't think it will be that much of a slowdown, anyway. The Go RE engine won't blow up in your face like all the other back-referencing engines can.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.