[pmwiki-devel] RFC: Community poll for PageList link/category arguments

0 views
Skip to first unread message

Petko Yotov

unread,
Dec 25, 2021, 3:13:38 AM12/25/21
to Pmwiki Users, Pmwiki Developers
Hello,

I hope you are all safe, and happy holidays if you're celebrating!

I've been working on some new features for version 2.3.0 and I'd like
your input.

If you have a few minutes, please look at this page:

https://www.pmwiki.org/wiki/PITS/01475

...and consider which ones of the proposed implementations may suit your
wiki and your editors best, and add your name.

I'd like to see some comments/votes and to release 2.3.0 by January 8.
2022, which will include implementing and documenting the new features.

If you have questions or suggestions, you can add them to the page, or
reply to the mailing list.

Thank you in advance.

Petko

_______________________________________________
pmwiki-devel mailing list
pmwiki...@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel

Petko Yotov

unread,
Dec 27, 2021, 1:58:33 AM12/27/21
to ABClf, Pmwiki Users, Pmwiki Developers
Thank you Gilles, these are great questions. My replies below.

On 27/12/2021 01:28, ABClf wrote:
> I understand current installations won't be broken, yet I have a
> question about performance, concerning multiple link in pagelist :
> when benchmarking the same pagelist, targeting a one single link,
> native link=mylink against cookbooked links=mylink,
> it looks to me that native is faster ; am I right ?
>
> https://www.languefrancaise.net/Test/PageListMultiple (around 3)
> https://www.languefrancaise.net/Test/PageListNormal (around 1,70)
>
> If so, would it be possible to get the best of each : native for one
> target search, and complex for complex queries ?

First, this is a fabulous installation with 64817 pages! It will be
great indeed to benchmark the new feature.

Second, we need to look at the numbers between the start and end of the
functions, so the difference between the core and the recipe are even
greater:

422: 00,69 PageListTermsTargets begin count=64817
425: 01,09 PageListTermsTargets end count=164

1.09-0.69=0.4 seconds for the core processing

422: 00,76 PageListMultiTargets begin count=64817
425: 03,17 PageListMultiTargets end count=164

3.17-0.76=2.41 seconds for the recipe, that's about 6 times more
CPU-intensive.


Indeed, in 2.3.0, when you have link=SinglePage, then the original
scanning method is used, so the times should be very close to the
current ones.

When you're searching for links to multiple pages or to wildcards, the
new core algorithm is different from the one in the recipe, with fewer
loops, and I believe (hope) it will be faster than the current recipe.

Again, your installation will be a great place to verify this.


> Question 2, for this paragraph :
>
> link=PageA,PageB should list pages linking to "AT LEAST ONE" among
> PageA and PageB.
> link=+PageA,+PageB should list pages linking to "BOTH" PageA and PageB.
>
> I would like to know if case bellow is involved in the choice.
> In my case, I have a group made of pages named 1900, 1901, 1902, etc.,
> for aggregating words by years.
> Then, for the query
> links=Year.199*
> expected output would be to list pages having a link to any year page
> from 1990 to 1999 (and not list pages having a link to all pages
> included in the range).

link=Year.199* or link=+Year.199* lists pages linking to any page with
the pattern, not to all pages, whether the target page exists or not.

The wildcard characters are about characters, not about existing pages:

? = exactly one character, any character
* = between zero and any number of any character(s)


The poll is more about a case like link=GroupA.*,GroupB.* then we need
to decide how we want it to behave.


Should it require at least one link to GroupA OR to GroupB like in the
recipe?

Should it require at least one link to GroupA AND at least one link to
GroupB? Or should this case be written as link=+GroupA.*,+GroupB.* ?


Petko

Petko Yotov

unread,
Dec 27, 2021, 3:05:41 AM12/27/21
to ABClf, Pmwiki Users, Pmwiki Developers
On 27/12/2021 07:57, Petko Yotov wrote:
> When you're searching for links to multiple pages or to wildcards, the
> new core algorithm is different from the one in the recipe, with fewer
> loops, and I believe (hope) it will be faster than the current recipe.

On PmWiki.org we only have about 10K pages, and here is our benchmark:

https://www.pmwiki.org/wiki/Test/CorePLMT2

Single page:
link=PmWiki.BasicEditing

17: 00.22 00.21 PageListTermsTargets begin count=10109
20: 00.25 00.24 PageListTermsTargets end count=70

That's 0.03 seconds.


Wildcard, multiple pages:
link=PmWiki.BasicEditin?,NoSuchGroup654.NoSuchPage987

52: 00.32 00.30 PageListTermsTargets begin count=10109
55: 00.39 00.37 PageListTermsTargets end count=72

That's 0.07 seconds, only 0.04s or 1/25th of a second slower than the
first one. I think it might be good enough for many people.

Note that the second search is case-insensitive, it returns 2 additional
pages which link to Pmwiki.BasicEditing (lowercase "w" in "Pmwiki")
which doesn't exist.

Not sure if I should do something about this case, or not.

Petko

Reply all
Reply to author
Forward
0 new messages