[TIMOB-26742] TiAPI: App launch slowed down by 2-5 seconds in SDK 8
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Critical |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2019-01-24T19:28:00.000+0000 |
Affected Version/s | Release 8.0.0 |
Fix Version/s | Release 8.0.0 |
Components | iOS |
Labels | n/a |
Reporter | Hans Knöchel |
Assignee | Christopher Williams |
Created | 2019-01-17T09:12:51.000+0000 |
Updated | 2020-01-23T20:18:32.000+0000 |
Description
When using SDK 8, the app launch is now extremely slow. It looks like the "core-js" libraries take waaay to long. It needs to be solved differently in order to be used in production apps. Any kind of logs or insight in our app can be shared with the core team.
[~hknoechel] Do you have any specific timings? We're not injecting polyfills into the app startup specifically yet. We're polyfilling based on "usage" - so if you're using features not supported by the OS's JS engine it'll inject the polyfill require into the file using it. So If your app.js is using them - or requiring files which do during startup, then yes it will have an impact on startup directly. So it *may* be polyfill causing the issue, but it's also entirely possible it is not. The common JS code we do load on startup could be a cause, which also does polyfill based on usage so loads some. It's hard to say without specific numbers to look at here. This PR would front-load the polyfill loading so it *does* hit all during startup: https://github.com/appcelerator/titanium_mobile/pull/10567 but may actually improve performance if the scattered requires of polyfills is slow.
[~cwilliams] I haven't measured it, yet since we have some more things to clear this week before, but I can share our repo with you (all modules are includes in the project, so no additional setup required except cloning). Let me know via Slack if I can help. To clarify our situation, I am talking about the time between starting launching the app and seeing the first screen, not the compile time itself. But I think we're at the same page for that one already. *EDIT*: - Launch (SDK 8): 5.3740 seconds - Launch (SDK 7.5.x): 2.032 seconds Note: On SDK 8, this logs even continue nearly a minute (!) with hundreds or even thousands of path-loading related logs. See [this PR](https://github.com/appcelerator/titanium_mobile/pull/10572) to remove those logs.
In my testing this seems to be pretty specific to iOS itself and is due to an inefficient require implementation. On Android I believe we're properly caching things, so it takes ~217ms to load the app, whereas on iOS it took ~5.3s! I provided a very quick and dirty hack to aggressively cache requires on iOS which took that down to ~1.25s. I need to iterate on that solution, though, as it is caching too aggressively - it does not account for requires of node modules from different base paths (so using two different versions of the same module would be broken with it as the first one loaded will always then be loaded).
Quick update - this is a huge performance gap between iOS and Android here. Android "cheats" and during build generates an index.json file with a listing of all the JS and JSON files in the app - and the require implementation uses that listing to check if a file exists. iOS actually attempts to load the file from the encrypted assets first, falls back to trying to load from disk, and **then** assumes it does not exist if both of those fail. Not great. So I'm testing two big changes here: using a cheat index.json for require file existence checks; and modifying the require implementation to do two passes: resolve the path to a full filename, then load it. Resolving as quick as possibly without actually loading lets us cache globally by the full filename/path - so we should have better caching behavior now as well. I slapped up a PR now, but I need to clean up my commits and ensure we pass all the tests before I'd consider the PR "ready" for review: https://github.com/appcelerator/titanium_mobile/pull/10640
8_0_X branch: https://github.com/appcelerator/titanium_mobile/pull/10640
Passed FR. Merged PR manually to 8_0_X and master branches.