Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#85 2015-05-10 14:27:55

ruud
Developer Emeritus
From: a galaxy far far away
Registered: 2006-06-04
Posts: 5,068
Website

Re: Making plugins first-class citizens

If we ever want TXP to be compatible with other databases, I don’t think it’s a good idea to use specific mysql functions.

I’m not sure where else 4.6-dev loses time compared to 4.5.7. Finding out would take me quite a bit of time and I wonder if – in the cases where this actually matters – it would be faster to optimize page loading by caching the result of the entire block of TXP code instead of micro-optimizing as we do now. There’s no point in gaining a few microseconds here and there if we lose more than that elsewhere in TXP.

For the example I gave, the runtime reduction is IMHO not enough to justify merging the suggested patches. Perhaps you can supply a comparison between txp-dev and txp-parser with a more complex bit of example code where it actually does pay off.

Offline

#86 2015-05-10 17:27:20

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

Re: Making plugins first-class citizens

Look, you care about loosing 0.1s in 4.6 (which I do too), and hesitate about gaining 0.1s by minor code changes. For me, it’s of the same order that storing textiled html rather than processing it each time — no real difference for a small article, but a better programming style. This said, caching blocks would be much more efficient, but probably yields a user decision whether to cache or not to cache. And txp users are not always tech savvies…

I’ve posted a simple proposal here, no much feedback atm.

Offline

#87 2015-05-12 05:53:24

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

Re: Making plugins first-class citizens

ruud wrote #290625:

If we ever want TXP to be compatible with other databases

We are considering Doctrine DBAL as a db layer for 4.6.

Offline

#88 2015-05-12 07:24:20

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

Re: Making plugins first-class citizens

ruud wrote #290625:

If we ever want TXP to be compatible with other databases, I don’t think it’s a good idea to use specific mysql functions.

You are right. Anyway, I think I’ve been mistaken by db cache, the real difference is rather 10 than 25%, sorry. However, static $column_map looks more natural in 4.5, but I don’t know how custom fields will be implemented in 4.6 and above.

Offline

#89 2015-05-12 20:00:48

ruud
Developer Emeritus
From: a galaxy far far away
Registered: 2006-06-04
Posts: 5,068
Website

Re: Making plugins first-class citizens

Let’s do some insane benchmarks. I’ve used wet_lorem_ipsum to generate 10.000 articles. I’m using your real world example to generate a page.

master:
23.169 0.483281 5638Kb
18.741 0.346480 5633Kb
20.098 0.420495 5634Kb
21.685 0.454559 5633Kb
22.746 0.494149 5633Kb

commit a406449 (new parser)
18.512 0.497731 5795Kb
17.086 0.470386 5794Kb
18.341 0.492000 5794Kb
18.387 0.467958 5794Kb
16.653 0.482271 5794Kb

commit c6994fd (parse_else)
16.940 0.424650 5769Kb
16.660 0.496910 5764Kb
17.226 0.473320 5769Kb
15.010 0.810858 5764Kb
15.207 0.459667 5764Kb

commit d970063 (various small optimisations)
14.164 0.411276 5757Kb
13.505 0.624712 5754Kb
13.964 0.492843 5754Kb
14.460 0.430434 5753Kb
14.862 0.501641 5753Kb

commit 842c22a (short tags)
14.767 0.434522 5756Kb
12.060 0.419026 5753Kb
14.329 0.456034 5753Kb
13.762 0.963029 5753Kb
15.032 0.456183 5753Kb

splat modifications:
13.508 0.480264 5775Kb
13.043 0.413073 5768Kb
13.324 0.458568 5768Kb
13.388 0.451295 5768Kb
12.419 0.481908 5768Kb

These results are varying way too much, even though the server is idling most of the time. Server is a XEN based VPS. Things one might conclude are:
  • adding short tag support doesn’t have to cost anything in performance.
  • splat optimisations don’t seem to help.
  • the various small optimisations may be more interesting to apply than rewriting the parser.
  • this is definitely not a realistic real-world test.
  • i need a more reliable (less fluctuating) way to benchmark.

Offline

#90 2015-05-12 20:35:15

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

Re: Making plugins first-class citizens

ruud wrote #290611:

Looks like 4.6-dev somehow got a lot slower compared to 4.5.7. WTF happened in -dev?!

Classes, probably. My guess is it’s a combination of the class loader, tag registry, singletons, adapters, factories, layers of abstraction and all that other OO “goodness”, which adds up to a more maintainable, albeit slower system.

Ah the good old days of functional programming where you knew exactly where you were: one stack, push, pop, easy. In the light of your findings (especially about the tag registry being called twice), your optimisations are going to be even more important to counteract the overheads of OO, if that is what is causing the slowdown.


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

Online

#91 2015-05-12 22:20:42

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

Re: Making plugins first-class citizens

ruud wrote #290694:

Let’s do some insane benchmarks. I’ve used wet_lorem_ipsum to generate 10.000 articles. I’m using your real world example to generate a page.

Wow, it’s almost twice faster! 10.000 is probably not so common, but in my tests I get 20-30% acceleration starting with 50 articles. This should suffice to avoid 4.6 slowdown.

Things one might conclude are:

  • adding short tag support doesn’t have to cost anything in performance.
  • splat optimisations don’t seem to help.
  • the various small optimisations may be more interesting to apply than rewriting the parser.
  • this is definitely not a realistic real-world test.
  • i need a more reliable (less fluctuating) way to benchmark.

Amazing result, but you don’t mean that commit d970063 alone gives these figures? I haven’t noticed much effect of splat optimization neither, but your real life example seems to be for it. Great work, whatever!

Offline

#92 2015-05-12 22:47:37

ruud
Developer Emeritus
From: a galaxy far far away
Registered: 2006-06-04
Posts: 5,068
Website

Re: Making plugins first-class citizens

The commits I listed are cumulative, so each one builds on the one before. Ideally you should see the runtimes go down with each commit shown (apart from short tags which wasn’t a speed optimisation).

Offline

#93 2015-05-15 17:46:35

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

Re: Making plugins first-class citizens

Re splat, for 4 attributes sha1 is ~10 times faster than preg_match_all, and md5 is even faster. But the regex pattern is very simple, so preg_match_all takes only 10-5s and the difference is unnoticeable. But as the number of attributes grows, the runtime of preg_match_all seems to grow faster than sha1 (~20x slower for 8 attributes). So, I would optimize splat nevertheless.

Offline

#94 2015-06-19 11:14:57

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

Re: Making plugins first-class citizens

Did anything happen with this?

Offline

#95 2015-06-20 10:32:54

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: Making plugins first-class citizens

philwareham wrote #291691:

Did anything happen with this?

I don’t know. Seems to be a lot of back and forth about trivial values, getting the last word in, and such. ;)

Offline

#96 2015-06-23 10:48:29

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

Re: Making plugins first-class citizens

philwareham wrote #291691:

Did anything happen with this?

There was a pull request which wasn’t ready to be merged. Then: Crickets.

Offline

Board footer

Powered by FluxBB