Open aslanvaroqua opened 8 years ago
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.
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.
https://www.polymer-project.org/1.0/start/first-element/intro
Measured with Chrome. Finished 358ms, Loaded 431ms
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
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.
I will provide more information in a few. Just got into the office.
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.
@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.
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.
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.