Add lazy Renderer service to speedup page load time

[umpirsky]

Fixes #59.

[coveralls]

Coverage decreased (-1.9%) to 98.091% when pulling 41ad4f8 on ChessCom:fix/issue-59 into dd8ea15 on scheb:master.

[coveralls]

Coverage decreased (-1.9%) to 98.091% when pulling 41ad4f8 on ChessCom:fix/issue-59 into dd8ea15 on scheb:master.

[coveralls]

Coverage decreased (-1.9%) to 98.091% when pulling 41ad4f8 on ChessCom:fix/issue-59 into dd8ea15 on scheb:master.

[coveralls]

Coverage decreased (-1.9%) to 98.091% when pulling 41ad4f8 on ChessCom:fix/issue-59 into dd8ea15 on scheb:master.

[coveralls]

Coverage decreased (-0.5%) to 99.523% when pulling 5cebf92 on ChessCom:fix/issue-59 into dd8ea15 on scheb:master.

[coveralls]

Coverage decreased (-0.5%) to 99.523% when pulling 4c35b23 on ChessCom:fix/issue-59 into dd8ea15 on scheb:master.

[coveralls]

Coverage decreased (-0.5%) to 99.523% when pulling e7f0238 on ChessCom:fix/issue-59 into dd8ea15 on scheb:master.

[coveralls]

Coverage decreased (-0.5%) to 99.523% when pulling ea91992 on ChessCom:fix/issue-59 into dd8ea15 on scheb:master.

[coveralls]

Coverage remained the same at 100.0% when pulling eeba4a3 on ChessCom:fix/issue-59 into dd8ea15 on scheb:master.

[umpirsky]

@scheb Can you review please?

[coveralls]

Coverage remained the same at 100.0% when pulling 23f17a2 on ChessCom:fix/issue-59 into dd8ea15 on scheb:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 23f17a2 on ChessCom:fix/issue-59 into dd8ea15 on scheb:master.

[scheb]

Looks good, thanks!

[zerkms]

So what was the "problem"? The templating service?

I'm not sure I understand the roots of the problem just looking at this code.

[zerkms]

Btw, why is it the doctrine dependency now?

[umpirsky]

@scheb Thanks for blazing fast reaction! 👍

@zerkms Yes. It's not a dependency, it's dev dependency, we need it for tests.

[zerkms]

@umpirsky but what about some explanation? Was it templating? If so - how your app is structured so that it does not use templating service? Since all mine always use it even for API (fosrestbundle)

[umpirsky]

@zerkms Yes, they use it, I just wanted to remove this bundle services from the slowest list. Plus, this seems like a good decoupling.

[zerkms]

Yes, they use it, I just wanted to remove this bundle services from the slowest list

If the app uses it anyway - this change is harmful: it increases CPU + memory load

@scheb so, the change you accepted made the bundle slower and more memory hungry in favour of @umpirsky performance statistics to look "better" ("better" here in quotes because it only spread the slow path into multiple paths, but in fact does not improve anything). "Looks good, thanks!" --- does it really look that good to you? :-S

Plus, this seems like a good decoupling.

Cannot agree with it.

Colleagues, I understand that you like nice graphs, but this change makes totally no sense.

[umpirsky]

@zerkms After this you can override Renderer and use other template engine then Twig.

Adding 2 services is minor since typcal Symfony app can have more then thousands of services.

[zerkms]

Adding 2 services is minor since typcal Symfony app can have more then thousands of services.

That, plus few extra lazy wrappers. All of that only for someone's graphs to look better.

After this you can override Renderer and use other template engine then Twig.

If only it was a problem.

I'm off anyway - I shared my thoughts, but you apparently value your performance metrics over actual performance. So, whatever.
☮

[umpirsky]

@zerkms I appreciate your opinion, but this is open source project and there is many ways people use this software. We are putting efforts to make it as flexible as possible with performance in mind of course. I still think that number of services is not a bottleneck.