Performance slower in 0.12.1 than 0.11.0

[Yozons eSignForms]

I actually reported this as an aside in another issue, but wanted to make it its own topic to see if there's a simple tweak that can restore the prior performance.

When converting HTML files using 0.11.0 rc1, 'time' shows:

real    0m1.672s
user    0m1.517s
sys     0m0.170s

Compared to the same HTML files being converted by wkhtmltopdf 0.12.1 (with patched qt), 'time' shows:

real    0m8.220s
user    0m6.924s
sys     0m1.173s

That's nearly 5 times slower with the latest version than the previous.  The "Printing pages (6/6)" appears to be where the main extra time comes from.  Unfortunately, the previous version does not support WOFF, though it ran fast.  Also, adding HTML files seemed to make little difference to the overall speed.  The 0.12.1 version seemed to take an extra second or so as additional HTML files are included.

Anyway, hoping that some change that took place between the versions will seem like a likely culprit for the performance change since it seems so dramatic.

[Ashish Kulkarni]

Seems it could be something to do with your CSS, there was a similar
issue reported on the bug tracker:

https://github.com/wkhtmltopdf/wkhtmltopdf/issues/1510

Also note that the proper place to report issues is at Github, not via
the mailing list :-)

[Yozons eSignForms]

On Tuesday, November 25, 2014 11:30:56 AM UTC-8, Ashish Kulkarni wrote:

Seems it could be something to do with your CSS, there was a similar
issue reported on the bug tracker:

https://github.com/wkhtmltopdf/wkhtmltopdf/issues/1510

That is the culprit for us, too. 

With border-radius (used once in the HTML file):

real    0m19.831s
user    0m16.260s
sys     0m2.644s

With border-radius removed:

real    0m2.198s
user    0m1.279s
sys     0m0.162s

 

Also note that the proper place to report issues is at Github, not via
the mailing list :-)

Sorry about that, but my take is that I'm first doing a discussion to see what it all means, and only if it's a new bug I've found would I report it at github (only because I monitor the mailing list, but not github as I don't do any development work on it).  In this case, though, it seems there's already a bug report and I look forward to the Qt 5 update whenever that occurs.

Thanks for the CSS tip you, sontek and sanfords reported in that issue as it should help us out as we can live without rounded corners for a bit.

[Chris Tate-Davies]

That's interesting. Note to self, check templates tomorrow. 

--
===================================================
You received this message because you are subscribed to the "wkhtmltopdf General" group.
To post to this group, send email to wkhtmltop...@googlegroups.com
To unsubscribe from this group, send email to wkhtmltopdf-gen...@googlegroups.com
 
For more options, visit this group at
http://groups.google.com/group/wkhtmltopdf-general?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups "wkhtmltopdf General" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wkhtmltopdf-gen...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ashish Kulkarni]

You might want to take a look at this blog post which includes a list
of which CSS selectors can be very expensive and should be avoided in
wkhtmltopdf:

http://perfectionkills.com/profiling-css-for-fun-and-profit-optimization-notes/

[Yozons eSignForms]

Interesting list. What's odd, though, is that wkhtmltopdf is rendering much slower. Removing border-radius shaved 17 seconds on page printing time for -- and there is exactly one in each file.  Yet those pages all render without any time delay in any browser, including webkit based ones.  It's not about calculating border-radius that is causing the slowdown in wkhtmltopdf -- something else has to be wrong when it's rendered outside of a browser.