Skip to content
This repository has been archived by the owner on Dec 19, 2017. It is now read-only.

slow initial render #702

Open
aslanvaroqua opened this issue Jul 6, 2016 · 6 comments
Open

slow initial render #702

aslanvaroqua opened this issue Jul 6, 2016 · 6 comments

Comments

@aslanvaroqua
Copy link

I have a site that was using polymer < 1.0. That sites index page loaded quickly. After upgrading, the header loads slowly and finally renders. I expected performance to improve but it actually got slower. What would cause this? It's quite annoying because we spent 2 weeks upgrading and now we have a slower site.

@zoechi
Copy link

zoechi commented Jul 7, 2016

After upgrading to what? What browser? What does the code do? Can you provide a repo project?
With this little information it's not possible to do any diagnosis.

@jonboj
Copy link

jonboj commented Jul 7, 2016

Had similar suspicions. Tried to do some rough load time measurements with Chrome, comparing JS polymer with dart polymer. This was done to identify the overhead introduced by the dart environment. All on localhost web server.

JS polymer project

https://www.polymer-project.org/1.0/start/first-element/intro

Measured with Chrome. Finished 358ms, Loaded 431ms

Dart polymer project

Example project generated by dev environment. Dart2js builds with Chrome.

Finised 728ms, Loaded 728ms

Since the fonts.google.api is an external request, these are removed. Which gives
Finised 472ms, Loaded 676ms

This includes a 'Not Found' request to index.bootstrap.initialize.dart
Which is measured to 74ms

Comparision

With some loose estimate the load time is increased from 450ms to 650ms going from JS to Dart. So at max 200ms, so not huge. Maybe this difference increases, when the project grows, this is not measured here.

@aslanvaroqua
Copy link
Author

I will provide more information in a few. Just got into the office.

@jonboj
Copy link

jonboj commented Jul 15, 2016

Maybe an issue here. On phone the initialization locks up the app for like a seconds. At the moment sustainable, but there is a concern, when the project grows.

Measured with Chrome Timeline tool on desktop. On a phone with weaker cpu this should scale linear.
Minimal project Evaluate(index.bootstrap.initialize.dart.js) 210ms

Small project - Four custom element, max 500 lines dart aside the elements, no references to external frameworks
Evaluate(index.bootstrap.initialize.dart.js) 470ms

--- Update
The Chrome Timeline tool gives a lot of information. Debugged further, the Evaluate(index.bootstrap.initialize.dart.js) 470ms included instantiation of sub elements in one attached method. By postponing these, cut down Evaluate(index.bootstrap.initialize.dart.js) to 350ms. Still left with 3 instances of Recalculate Style each 17ms.

Removing the one instance of <paper-input> element in the minimal project, comparing with 10 instance gives:
0 x <paper-input hidden ...> -> Evaluate(index.bootstrap.initialize.dart.js) 140ms
10 x <paper-input hidden ...> -> Evaluate(index.bootstrap.initialize.dart.js) 266ms so 12ms pr. element.

So in order to avoid the lockup at start, a solution could be postponing the instantiation of the elements in the app. - Redesigned the app with at start dialog, and postponed rest of instantiation, this cuts down the mobile start time of the app to an acceptable level. Furthermore cached loading with service workers giving an user startup experience not differing from other apps like WhatsApp.

@jonboj
Copy link

jonboj commented Jul 25, 2016

@aslanvaroqua what are your findings on this? At the moment I don't suspect extra startup time has been added at 1.0, so maybe we should consider to close this issue. If new info/data comes up it could be reopened.

@jonboj
Copy link

jonboj commented Aug 18, 2016

Have digged a little deeper into this. The initial startup time consist of two major contributions.

a) From js Polymer the initial population of elements. Pr. element type this is the call to Polymer({..}) e.g. https://github.com/dart-lang/polymer_elements/blob/master/lib/src/iron-collapse/iron-collapse.html#L81
This trigger a significant amount of processing pr. element type.

b) The load/parse/evaluate of the index.html and index.bootstrap.initialize.dart.js The evaluation time includes initial population of elements.

The both scales with the size of the project, while a) maybe of most concern, since it scales linear with the number of element types.

For desktop app not a concern, but for mobile apps the startup time have to be trade of with the size of the app. Every new element type slows down the start. Anyhow for a) hard to do better, than what is provided by js Polymer.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

3 participants