Skip to content
This repository has been archived by the owner on Nov 16, 2020. It is now read-only.

Encoding template data and rendering templates has a lot of overhead working with already-fulfilled futures #52

Closed
MrMage opened this issue Apr 2, 2019 · 3 comments
Labels
enhancement New feature or request

Comments

@MrMage
Copy link
Contributor

MrMage commented Apr 2, 2019

After the optimizations proposed in https://github.com/vapor/template-kit/pull/50/files, a significant portion of the time needed to encode/render templates is spent calling NIO operations on already-fulfilled futures (see vapor/leaf#137 for the corresponding benchmark):

Screen Shot 2019-04-01 at 11 06 29

vapor/core#199 has alleviated this problem, but it is still significant. Essentially, the current render process consists of linking thousands of small futures — at least one for each variable printed in the template. Almost all of these futures are already fulfilled when they are created, because none of TemplateKit's/Leaf's default tags perform any non-blocking operations.

One option to alleviate this could be to make the rendering process itself blocking. I understand that the option to have non-blocking ("future") passes in the encode/render steps is a great option, but it does not seem to be used in practice right now. In addition, users could still manually "prepare" the "future" parts of their templates before calling a "blocking" render pass that simply processes the already-prepared template data in one fell swoop.

Another alternative would be to introduce a FutureOrFulfilled<T> type, which could use shortcuts when it has already been fulfilled at creation time (e.g. not submitting blocks to the run loop). However, that would still retain some overhead and make the implementation more complicated.

I'm not sure if the approach suggested above would be the right way forward, but it feels like template rendering in particular creates so many already-fulfilled futures that the overall render time is impacted significantly.

@MrMage
Copy link
Contributor Author

MrMage commented Apr 3, 2019

Update: apple/swift-nio#943 should significantly alleviate these issues once this project moves to NIO 2.

@MrMage
Copy link
Contributor Author

MrMage commented Apr 11, 2019

This will be improved upon by vapor/core#203 (comment). The remaining runtime might be more due to other factors, e.g. date formatting and String.htmlEscaped() being slow.

In any case, I think that rendering 500 table rows of a semi-complex model (see https://github.com/vapor/leaf/blob/e06abf2e5cff23e5e8c8fa096718258ee27f4846/Tests/LeafTests/LeafTests.swift#L556) should take less than 500 milliseconds.

@tanner0101 tanner0101 added the enhancement New feature or request label Apr 25, 2019
@0xTim
Copy link
Member

0xTim commented Nov 16, 2020

Closing as template kit is not used with Vapor 4 and new behaviour is in LeafKit - if this is still an issue please create an issue on that repo. Thanks!

@0xTim 0xTim closed this as completed Nov 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants