Is there a way to slow down ES6, the operating environment or the operating system?


#1

Is there a way to manually slow down the plugin environment (or operating system)?

I’ve recently been working on a large project with a lot of artboards and thus a lot of exports and on a MacBook a half decade old it took a few seconds to complete but surprisingly when I tested on a new tablet PC it took 20x as long.

Is there a way that I can tell ES6 to run 10 - 20 x slower so that I can simulate the environment and see what areas could be improved?

As an example, browsers have a bandwidth throttle option that you can enable so you can experience a page being loaded on a slower network.

throttling

I know this isn’t how it works but in code using 3 examples:

ES6Settings.speed = .2;

XDPluginSettings.speed = .5;

var os = require("os");
os.speed = .5;

I’d also be open to changing something in the operating system.

I remember reading about older Windows systems where each running application receives a slice of time sort of like multi threaded systems. The application in the foreground received more time shares than an application in the background. And in Windows you could change the mode to be user mode or server mode. IIRC In server mode all the services received an equal share of time.

So if you can change the amount of time slices an application had you could slow it down. This was a while ago and I haven’t been able to find any information on doing this manually in OSX or Windows but this method would also be an option.


#2

While Chrome developer tools is on the roadmap, I’m not sure if network throttling is included as part of that.

Perhaps @kerrishotts can confirm.


#3

This definitely illustrates the importance on testing on a wide variety of configurations. This is true of browsers and of XD as well. There’s no method by which to slow down the JS environment, and even if there were, it wouldn’t be necessarily be terribly accurate (for example, I/O is often highly variable, and a multiplier won’t reflect that accurately).

As for network requests, the CDT that is coming to XD will not support throttling initially. We should consider adding it, but this initial release of CDT is focused more around the debugging side of things, than it is around the network side.

What should be coming down the road as well is better ways to measure your performance – this would be critical for determining why your plugin runs so slowly on a new tablet. For example, it might be I/O related (some tablets use notoriously slow flash storage), but it might be something else. Some high resolution timers would help you figure out where time is being spent. Tracing in CDT would as well, although that’s a bit further down the timeline.


#4

The network / bandwidth throttling option is not a feature request for me. The high resolution timer and debugging sounds great! :slight_smile:

The tablet IO surprised me since I thought SSD or flash storage would be automatically mean performant but apparently not.


#5

Yeah, you’d be surprised. Some of the flash storage used in some tablets can be really quite slow. What particular tablet did you try on?


#6

It was a mid-range Surface Pro. Reading 20 json text documents for 20 artboards from disk took ~30 seconds and writing 20 text documents at ~30kb each took 38 seconds. I’ll have to do more testing of course. I’ve since moved to using the pluginData property and we’ll see how that goes. :crossed_fingers: