Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
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
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
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
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
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
- 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
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
Offline
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
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
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
Re: Making plugins first-class citizens
Did anything happen with this?
Offline
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
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