Problem/Motivation
In #2160643: Add status report "requirement" for Twig C extension for PHP a status report "requirement" for Twig C extension for PHP was added. However, the wording exceeds expectations.
The justification to introducing this check was based on a) a post from 2011 on why we needed to have a C extension to speed up the slow and already-improved PHP Twig_Template::getAttribute function and b) a 2013 article which claimed we could get a perf increase of ~15%...but that was with PHP 5.3. We're now requiring 5.5.9 at a minimum, and benchmarks show PHP 7 greatly improves overall PHP performances.
https://github.com/twigphp/Twig/issues/1695 also discusses porting the Twig C extension to PHP 7 but it's unclear at this point if it'll ever happen. Solid benchmarking is required to determine if PHP 7 improvements are making the Twig C extension obsolete or if it's still something we should consider recommending. In doubt, we should no longer recommend it on the reports page and thus prevent confusion from arising as a result.
Proposed resolution
Remove the requirement altogether.
Remaining tasks
None. Patch is trivial and has been written already.
User interface changes
Reports page no longer shows a requirement for the Twig C extension.
API changes
None.
Data model changes
None.
Comment | File | Size | Author |
---|---|---|---|
#32 | drupal-2568247-32-twig-c.patch | 1.2 KB | gapple |
#28 | interdiff_26-28.txt | 920 bytes | heddn |
#28 | drupal-make_the_twig_c-2568247-28.patch | 1.66 KB | heddn |
Comments
Comment #2
dawehnerIt would be great to actually have numbers on 5.5
Comment #3
anavarreFirst, apologies for the very unscientific benchmarks on my busy laptop with Rasmus' php7dev box.
The quick methodology I used was to switch from PHP 5.5, then PHP 5.6 and finally PHP 7 without the Twig C extension and then with it.
Command used was (hitting Bartik's front page of a fresh D8 site):
$ ab -n 1000 http://d8.vbox/
...and I simply ran it twice to have 'cold' opcache numbers first.
PHP 5.5
Without the Twig C extension
With the Twig C extension
PHP 5.6
Without the Twig C extension
With the Twig C extension
PHP 7
Without the Twig C extension
With the Twig C extension
Comment #4
star-szrThanks @anavarre!
It would be interesting to see these numbers with a lot more content on the page than a clean install. Even with a clean install they still seem pretty relevant to me - 2.5ms on PHP7 with warm caches seems pretty significant and with closer to a real world scenario the difference would likely be higher. Whether this qualifies as "greatly" might be very subjective.
Comment #5
dawehnerAre you sure we could trust
on PHP 7? Its around as fast as PHP 5.5 without it. Do you mind including the standard derivation of those values?
Comment #6
star-szrOh I read it wrong. So it's possibly making things slower on PHP 5.6 and PHP 7 when the caches are warm? Hmm.
Comment #7
anavarreMethodology
Render complexity
Used devel_generate to create 100 nodes. Used Views to create an unformatted list of all 100 nodes on the frontpage. This should be more complex to render.
Results
Without the Twig C extension
With the Twig C extension
PHP 5.5
PHP 5.6
PHP 7
Oops. Got the below issue this time so I'm currently unable to provide numbers
Comment #8
anavarreIn case this helps...
Comment #9
hoff331 CreditAttribution: hoff331 as a volunteer commentedFrom anavarre's second round of tests, the Twig C extension appears to be making things worse. I agree with Cottser, the word "greatly" is subjective and may set unrealistic expectations. Simply changing the status page to read, "Enabling the Twig C extension may increase rendering performance" will help until further benchmark testing is performed.
Comment #10
star-szrI think we need a reroll here, the patch no longer applies. I have no strong feelings towards either the word "can" or "may" here :)
Comment #11
anavarreComment #12
dawehnerSo according to the benchmarks it makes things worse, sounds like recommending in that case is kinda pointless :)
Comment #13
anavarre#12 Honestly I'd be wary of my benchmarks. Maybe someone else can confirm/deny?
Comment #14
wahono77 CreditAttribution: wahono77 commentedWithout C extension, Drupal 8 is very slow after even after DOM loaded fully.
I read in http://twig.sensiolabs.org/doc/installation.html#installing-the-c-extension that Twig 1.4 is added C Extension into core.
Why Drupal 8 don't use twig 1.4. For shared hosting, install Twig C Extension is impossible.
regards
Comment #15
star-szrHi @wahono77, we use a version much newer than 1.4. By adding to the (Twig) core they only meant it's not an additional download. As far as I know it's impossible to install a C extension in the way you are talking about (i.e. on most shared hosting with no intervention).
Are you sure it's Twig that's slowing things down? After the DOM is loaded Twig is finished its work (unless you are doing Ajax requests or something) so I'm not sure it's fair to pin any slowness you're seeing on Twig.
Comment #16
wahono77 CreditAttribution: wahono77 commentedI don't know exactly what's the reason of slow (delay) after DOM loaded, all link, etc can not be clicked.
In my hosting C extension doesn't active.
Please try in http://acosinfo.com/contoh-animasi
After all content loaded, there are some millisecond delay and you can not click any URL or button there.
And after I try Drupal 8 in https://simplytest.me/ (with C extension enabled), this problem doesn't happen there.
regards
Comment #17
star-szr@wahono77 I don't think that has anything to do with Twig, sorry. It's more of a coincidence that the simplytest.me server has the C extension enabled. More likely the slowness might be coming from custom JavaScript or a JS library on your site.
Comment #18
joelpittet@wahono77 I agree with @Cottser here, it's likely JS loading assets issue. May want to run it through http://www.webpagetest.org/ and track down the front end performance. After stuff shows in the browser it's all on the front-end performance of the CSS selectors, JS blocking calls and assets. Most likely JS blocking calls. Consider opening up a new issue for this issue. May have something to do with the asset placeholder stuff that got in before RC.
EDIT: looks like CSS/JS aggregation is not turned on your site. That should help things a bunch.
Comment #19
mstrelan CreditAttribution: mstrelan commentedThis requirement should not appear if you're running PHP 7, at least until Twig compiles on PHP 7. See https://github.com/twigphp/Twig/issues/1695
Comment #20
joelpittetThis actually still needs the :url placeholder, this patch looks to have reverted that. #19, @mstrelan would you mind maybe wrapping this in a condition and posting a new patch with your suggestion?
Comment #21
mstrelan CreditAttribution: mstrelan commentedAdded
version_compare()
, removed the word "greatly" and fixed the :url placeholder.Comment #22
piyuesh23 CreditAttribution: piyuesh23 at QED42 commentedComment #23
gappleversion_compare()
expects a string, so probably best to avoid the implicit conversion from an integer.Otherwise +1
Comment #24
star-szr@gapple thanks, good point. We can use 7.0.0 I think.
Comment #26
heddnComment #27
dawehnerCan we document why we check the PHP version 7 here>
Comment #28
heddnI wasn't sure how opinionated I should make the comment about performance gains with the extension so I opted to document the simple fact that a version of the extension does not exist.
Comment #29
joelpittetThis looks perfect to me and seems to address comments from above.
Thanks @heddn et al.
Comment #30
alexpottGiven that the evidence for performance improvement is not there should we just remove it entirely?
Comment #31
anavarreGiven https://github.com/twigphp/Twig/issues/1695 and the current lack of real-life numbers, I'd also tend to agree with #30. Also, we don't know if it's ever going to be compiled for PHP7 (does it even need it?).
Comment #32
gappleWithout a clearer benefit to installing the C extension, I agree it's probably better noted in documentation as a potential option and not a persistent item on the status page.
Comment #33
heddnI've already removed/updated it from a d.o. docs page a week ago (cannot find the link ATM). Is there anything else stopping this from RTBC?
Comment #34
star-szrI think we need an issue summary and title update based on the proposed solution :)
Other than that I think it's fine, it basically looks like a revert of #2160643: Add status report "requirement" for Twig C extension for PHP.
Comment #35
anavarreComment #36
anavarreComment #37
gappleSince the title and summary are updated, I think it's reasonable to move this back to RTBC
Comment #39
star-szrCommitted fb8cdd4 and pushed to 8.2.x. Thanks!
Comment #40
heddnThis seems trivial enough, can we backport to 8.1 too?
Comment #41
star-szrIt's technically a UI change so I'm a bit torn, that's why I didn't commit to 8.1.x. https://www.drupal.org/core/d8-allowed-changes
Edit: also a task.
Comment #42
joelpittet@cottser, this should not be considered a UI change. It's documentation at best and closer to a typo, IMO. Should be UI when it affects how you interface/use the product.
I've seen questions in vanDUG slack channel asking about this and PHP7 and were confused which referenced this issue.
Comment #43
alexpottI agree with @joelpittet an entry in the status report is not a UI. Also an incorrect recommendation could be considered a bug.
Comment #45
star-szrI'm good with that thanks @heddn @joelpittet @alexpott :)
Committed 5c01c88 and pushed to 8.1.x. Thanks!