Why does uglification speed up NativeScript startup times?


#1

I’ve been doing a bunch of research into the startup times of NativeScript apps in an attempt to document best practices, and there’s something I’ve noticed but can’t explain—the webpack plugin’s --uglify flag consistently speeds up my apps, and I have no idea why.

In my testing uglification drops startup times something like ~20–40%, which is crazy. On my Mac, the default NativeScript app starts up on a Nexus 5 emulator in ~2 seconds (using npm run ns-bundle), and that time drops to ~1.5 seconds with npm run ns-bundle --android --uglify. I’m also not the only one that’s noticed this optimization (see https://twitter.com/eddyverbruggen/status/873506250096619520).

So… um, why does this work?

It’s my understanding that the primary reason webpack speeds up my apps is by reducing file I/O—that is, webpack combines a bunch of files that would normally have to be retrieved one-at-a-time with require() calls. That makes sense to me. But what about uglification would speed up my apps?

To my knowledge uglify is primarily doing things that reduce the file size of my code—thing like removing whitespace, and shortening variable names—so I can see why it might reduce the file size of my app. But I’m not sure how that translates to a faster loading experience, as it would seem like the NativeScript runtime would still have to interpret the same amount of expressions regardless.

Is the uglification process doing something like removing dead code? Is there something else going on that I’m just missing? If anyone has any ideas here I’d really appreciate it. I haven’t done extensive benchmarking, so I might just be testing this wrong.

Thanks!


#2

Stanimira from our webpack team helped me out with this on Slack.

“In short, it enables the webpack plugin for uglifyjs which minifies the code and performs tree-shaking. The first one decreases the bundle size significantly and the initial load of the file is much faster. The second one eliminates the code that’s not used and doesn’t include it in the bundle. For example, if you have a plugin with 30 exported functions and you use only 2 of them in the app, uglify will detect that and won’t include the other 28 functions in your final app bundle. So, no time will be wasted to evaluate them at start up.”

Interesting to me that uglifyjs is what is doing the tree shaking here, but good to know.


#3

@tjvantoll really looking forward to see some “best practice” on official document !


#4

@tjvantoll can I use webpak, sbapshot and uglifyjs in my vanilla or its only for angular?


#5

@michaelsowah All of those tools work in both NativeScript Core and NativeScript Angular apps.


#6

@tjvantoll is snapshot supported yet on windows?


#7

@michaelsowah Yes, unfortunately.

The restriction is actually coming from a V8 tool that we’re using under the hood called mksnapshot. In the future we should be able to let you get this functionality by allowing you to build your apps on our build servers in the cloud, but for the forseeable future snapshot builds will be a Mac- and Linux-only feature.


#8

To add a bit to what TJ said, the V8 developers currently restrict building the tooling, and runtime for v8 by configuration. We’ve made several attempts to ignore the restriction and cross-compile the library and binaries for android, but with no success. I asked whether they have any intentions on officially supporting that in the future, but they came back to me with a definitive “No”. So I can’t tell with certainty, that you will be able to use the snapshotting tool anytime soon, if ever, on Windows.


#9

Thanks Pete.K i am already considering getting a Mac to work