[pmwiki-users] Question regarding slow page loading with attr set

[Petko Yotov]

Hi Hans,

I assume you updated pmwiki.php.

The CondAuth() caching only happens for markup, not if you call the 
function directly. And it only caches page permissions, as I mentioned 
per page and per level, after they are checked once, that means for a 
new page, or a new level (edit, upload), the page will be (re)opened, 
but if you re-ask for page+level perms that were previously checked, the 
cached perms are returned, without reopening the page file and 
rechecking the password.

I can experience this by adding 5 conditionals (:if auth edit:) in a 
password-protected page, and testing the old and the new versions.

New version (password-protected page), 5 conditionals:
0: 00.00 MarkupToHTML begin
1: 00.19 MarkupToHTML end
(1 additional ReadPage)

Old version (password-protected page), 5 conditionals:
0: 00.00 MarkupToHTML begin
1: 00.94 MarkupToHTML end
(5 additional ReadPage for the same page)

Password-unprotected page, 5 conditionals, same markup:
0: 00.00 MarkupToHTML begin
1: 00.00 MarkupToHTML end

Apparently every time a password is checked, it takes 0.188 seconds on 
average.

This is on a 5-year laptop, with SSD storage, and my operating system 
caches recently opened files to RAM, so I suspect the 0.188 seconds is 
mostly the waiting for password_verify(). If your system is different, 
the numbers will vary.

See also below:


On 14/04/2024 10:16, Hans Bracker wrote:
> But I still get a huge difference between loading time of a page
> having a password set with action=attr and the same without such
> setting.
> It doubles the loading time, or worse. And that is the case with the
> new subversion , the same as with the stable version.
> There is no real difference, perhaps a small speed increase.

In StopWatch, when the page is read (action=browse), you generally need 
to look at the first MarkupToHTML start and end (and avoid having 
(:markup:) in the page).

Everything before and after this first MarkupToHTML delay is outside of 
the page processing, may come from recipes, or from sidebars, headers, 
footers, PageActions loaded by the skin.

> A simple test page with just five (:if auth ..:) conditionals was 
> loading
> *  subversion: 2.8sec compared to 3 sec stable, with attribute set.
> * 1 sec for both with no attribute set.

What is the delay between the StopWatches of first MarkupToHTML start 
and end?

> If I disable the conditional markups, i.e. no markup calls from these,
> just five text lines,  then the page loading is:
> *  subversion: 1.34 sec compared to 1.61 sec stable, with attribute 
> set.
> * 1 sec for both with no attributes set.
> 
> Tested this with my amber skin, local machine,  without any
> conditionals in action or sidebar etc. pmwiki skin will be slightly
> faster.
> 
> I checked the calls to function ReadPage, and there is the same number
> of calls for both versions and both scenarios. I thought I may have
> less with the new caching helping, but no, exactly the same. So not
> sure what is going on.

With the new version, conditional markup should not reopen the same page 
for the same level, i.e. if you have (:if auth edit:) in multiple 
places, it should call ReadPage only once; multiple times with the old 
version.

By "only once" or "multiple" I mean the page reads caused by the 
conditional markup, that is in addition to any other pages that are 
opened for the query. For example, if you have a pagelist, in general 
all pages in the pagelist will also be opened. If you pull a 
PageTextVariable from a remote page, it will be opened. If you use a 
link like [[OtherPage|+]], the OtherPage will be opened to get its 
title. I mean, the number of pages opened depends on more than just what 
we did for caching the "auth" conditional.

Why don't you create 2 pages with the same content in the Test group on 
pmwiki.org and we'll try to debug it there.

Petko