Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
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
Offline
Re: Better (?) <txp:link_to_prev/next />
Hasn’t Robert confirmed it as a defect? Did you send in a patch?
Offline
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
Re: Better (?) <txp:link_to_prev/next />
jstubbs wrote:
Mmmm. My own “issue” regarding
if_sectionproblems 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
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_sortin some sorted_list takes about the same time that
SELECT ID, other_stuff FROM textpattern WHERE some_field>threshold ORDER BY some_sortSeeking 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
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
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
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
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
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
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