Skip to content

Removal of Snapshots support from NS 7.x #8926

Description

@NathanaelA

Reason why we are removing...

Reasons for removal:

  • High Support cost (> 800 issues)
  • High dev costs (breaks frequently, OS changes like Mac requires Docker, Arm64 mac... etc)
  • Bugs with Snapshots (snapshots are imperfect; they normally work -- but occasionally we have seen issues)
  • Having to create additional wrappers to keep native code from being snapshotted; snapshots have to be pure JS. Meaning plugins can easily break your snapshots, and we are constrained on how to write certain pieces of code.
  • Inflates app distribution size
  • Inflates app on device size
  • Android Only
  • On modern devices, snapshots are actually slower than having no snapshots.
  • Snapshots are not optimizable. Meaning all running code from inside a snapshot cannot take advantage of many v8 optimization features while running, so their is a constant runtime performance hit.

Replaced with Code Cache

  • Built into the v8 engine (supported by v8 maintainers), no additional support costs to us at all.
  • Faster than Snapshots in every instance except the very first boot. Very first boot, is slower because it has to build the cache.
  • Faster than Snapshots on Slower devices by a wide %.
  • Supported on both iOS and Android
  • Code-Cache built is native to the device, app space used is considerably less than w/ snapshots
  • Not inflating apk/ipk with snapshots for the the different platforms.
  • No runtime speed hit, all code is fully optimizable by v8

Actual Raw Numbers: (Lots of numbers)
I used the NS Grocery App under NS 6, because it has multiple screens, and uses Angular and of course snapshots work. I built all apps as tns --release. I did NOT uglify nor do --env.production as the idea was to create the slowest possible app with the most JS code easily. 😀

So I have a couple different sets of numbers

App Sizes

Stock App (no code cache, no snapshots just the app as is)
APK Size: 22.2m - Install Size: 7.5m

Code Cache App
APK Size: 22.2m - Install Size: 10m (after code cache is built)

Snapshot App
APK Size: 28.4m - Install Size: 21m

As you can see; not only is the APK w/ snapshots is 27% larger and on disk it actually is way over 200% larger than code cache and almost 300% larger than stock.

Time to JS Executed in Milliseconds (on real devices):

Fast number is on a very fast modern android device (Samsung S9, Android 10), Slow number is very old slow device (Samsung A3, Android 5.0.2) -- All numbers were averaged, took between 5 to 12 samples depending on the variation seen in the numbers).

Type First JS Fast First JS Slow Complete JS Fast Complete JS Slow
Stock Application 467 1646 835 3194
Code Cache First Only 695 2152 1100 3726
Code Cache All Boots (except first) 298 924 673 2392
Snapshots 487 1310 970 2980

Note: Using Code Cache with Snapshot is even slower than either; because first startup you still have to build the cache & each startup after you have to load in TWO files, the snapshot and the cache; which kills your startup performance.

Explaining the Numbers:

First JS means the time for the engine to startup and the point where snapshots / caches have loaded -- this is before anything has loaded, basically the very first line of JS executed.

Complete JS means that the JS has parsed, caches/snapshots have parsed and the app is actually running -- this is when we actually hit the login screen. (So this is probably the more important number to consider as it is what your clients will think as the speed of your app.)

So on a fast device, the stock app will get to the login screen in 835ms, and on a very slow device 3194ms (or 3.194sec).

A couple interesting things, on a reasonably modern fast device, using snapshots are actually > 16% SLOWER than no snapshots. However on a slow device the speed difference is around 7% faster.

With Code Cache there is a performance hit for the very first time your app runs. As you can see even on a fast device the hit is 265ms slower (31%) on the first boot than the stock app. However, every app start after that the speed is 20% faster. On a slow device this hit is about 16% but again on all the rest of the startups, the speed up is 33% faster than the stock...


To us at the TSC, it does not make any sense to continue maintaining complex tooling that as you can see it considerably slower than code cache in all areas except a single app start.


To enable code cache in NS 6 (Android only):

Edit the main app/package.json and add the key
"codeCache": "true"
to the android key. like so:
image

To enable code cache in NS 7 (Android and iOS)
Edit your main nativescript.config.ts file, and add
"codeCache": "true" to the android and/or ios sections.
image

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions