Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2013-01-15 15:32:11

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Better (?) <txp:link_to_prev/next />

Current (4.5.4) <txp:link_to_prev/next /> tags do not respect advanced sort orders, like sort="Section, Posted desc" or sort="DATE(LastMod)". Following this discussion, I have made some modifications in getNextPrev() and getNeighbour() functions to fix this issue.

It seems to work and is even faster than before on my server (but slower on my laptop). If someone is interested, the code (wrapped in a plugin) is below.

Last edited by etc (2013-03-16 11:17:45)

Offline

#2 2013-01-21 14:41:01

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Better (?) <txp:link_to_prev/next />

OK, let it stay in the territory of plugins for the moment.

Offline

#3 2013-01-21 14:48:38

jstubbs
Moderator
From: Hong Kong
Registered: 2004-12-13
Posts: 2,395
Website

Re: Better (?) <txp:link_to_prev/next />

Hasn’t Robert confirmed it as a defect? Did you send in a patch?

Offline

#4 2013-01-21 14:52:17

jstubbs
Moderator
From: Hong Kong
Registered: 2004-12-13
Posts: 2,395
Website

Re: Better (?) <txp:link_to_prev/next />

Mmmm. My own “issue” regarding if_section problems on 4.5.4 seems to have been removed..

Offline

#5 2013-01-21 14:59:01

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Better (?) <txp:link_to_prev/next />

jstubbs wrote:

Mmmm. My own “issue” regarding if_section problems on 4.5.4 seems to have been removed..

Seems it was invalid markup that might have been causing it.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#6 2013-01-21 15:06:16

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Better (?) <txp:link_to_prev/next />

jstubbs wrote:

Hasn’t Robert confirmed it as a defect? Did you send in a patch?

He did, and I have proposed a patch, but this is a new, more powerful solution, that respects any sort order. I have not submitted it as a patch because it needs some performance testing before. On fast servers its faster than the native one, but slower on my laptop. If some dev people are reading, I find that retrieving all IDs with

SELECT ID FROM textpattern ORDER BY some_sort

in some sorted_list takes about the same time that

SELECT ID, other_stuff FROM textpattern WHERE some_field>threshold ORDER BY some_sort

Seeking for the current article position $pos with array_seek and for its neighbors with SELECT ... WHERE ID IN ($sorted_list[$pos-1], $sorted_list[$pos+1]) is lightning fast, using the primary index.

But many testers are better than one.

Offline

#7 2013-01-21 15:13:52

jstubbs
Moderator
From: Hong Kong
Registered: 2004-12-13
Posts: 2,395
Website

Re: Better (?) <txp:link_to_prev/next />

Bloke wrote:

Seems it was invalid markup that might have been causing it.

That’s funny, changing the status of an issue to invalid renders it invisible, so I never saw Jukka’s reply. Some markup may have been invalid but I had strange results even with a very basic if - else scenario. Maybe I’m getting old! Anyway, back on topic. Sorry Oleg.

Offline

#8 2013-01-21 15:56:59

wet
Developer Emeritus
From: Schoerfling, Austria
Registered: 2005-06-06
Posts: 3,323
Website Mastodon

Re: Better (?) <txp:link_to_prev/next />

etc wrote:

because it needs some performance testing before.

You might want to try your approach for varying amounts of articles.

If I’ve read your code correctly, it employs array_search to lookup neighbours in an array of all articles matching the current list criteria like section, time, keywords.

It seems that array_search’s runtime depends on the size of the $haystack array and grows linear with the size of the haystack. I.e., more articles, less performance.

It might be interesting how the current core approach compares to your plugin when it has to look into large article sets.

Offline

#9 2013-01-21 17:00:57

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Better (?) <txp:link_to_prev/next />

wet wrote:

It seems that array_search’s runtime depends on the size of the $haystack array and grows linear with the size of the haystack.

Probably, but isn’t that true for SELECT ... WHERE ... ORDER BY ... query? The core approach uses two of them, the plugin takes one SELECT and one array_search.

It might be interesting how the current core approach compares to your plugin when it has to look into large article sets.

I did some testing, in a “typical” case (good LAMP server, about 250 articles) the plugin is ~25% faster, but slower on my laptop site copy. In average, the runtimes are of the same magnitude, but I have no very large site at hand to test.

Offline

#10 2013-01-21 17:27:48

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 9,007
Website GitHub Mastodon Twitter

Re: Better (?) <txp:link_to_prev/next />

etc wrote:

… but I have no very large site at hand to test.

Hi Oleg, one of my sites has over 1500 entries. If you want and promise you will not bring it to its knees I can grand you access. The problem is that it is not using the latest txp due to the postmaster plugin.

Last edited by colak (2013-01-21 17:29:50)


Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.

Offline

#11 2013-01-21 17:40:55

wet
Developer Emeritus
From: Schoerfling, Austria
Registered: 2005-06-06
Posts: 3,323
Website Mastodon

Re: Better (?) <txp:link_to_prev/next />

etc wrote:

Probably, but isn’t that true for SELECT ... WHERE ... ORDER BY ... query?

Apparently this is not universally true. According to this post MySQL uses a filesort algorithm to perform ORDER BY statements.

Filesort is based on quicksort. A clever quicksort implementation may be of O(log n) order while array_search is of O(n) order. MySQL’s runtime would only grow logarithmically with the haystack’s size.

about 250 articles

Try 2,500 or 25,000. How does this affect runtime?

Offline

#12 2013-01-21 17:42:19

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Better (?) <txp:link_to_prev/next />

colak wrote:

Hi Oleg, one of my sites has over 1500 entries. If you want and promise you will not bring it to its knees I can grand you access. The problem is that it is not using the latest txp due to the postmaster plugin.

Hi Yiannis, I only can promise not to hurt it intentionally, and it would need an upgrade to 4.5.4 anyway. Thank you for the proposal, maybe once I’m through with it on my server…

I was wrong about 250 articles, they are not all in a same section, so I was actually testing on smaller datasets. With ~150 articles, the plugin is a little slower than the core, but the reason is not array_search, I keep investigating.

Offline

Board footer

Powered by FluxBB