By deferring more code in the renderer and loading state earlier, we
improve startup time by another 90ms!
Before: 507 unique requires (1270-1280ms)
After: 506 unique requires (1180-1190ms)
In Electron apps, the cost of large modules is very real.
fs-extra is very convenient, but removing it caused 50 fewer unique
files to be required(), resultin in 60ms faster startup!
Before: 557 unique requires (1330-1340ms)
After: 507 unique requires (1270-1280ms)
Fixes two portable app bugs, to make the app fully "silent", not just
"portable". This means that not only are all data files stored in the
"Portable Settings" folder, but the app should leave no trace on the
host system.
- Disable Electron's single instance mode so no lock file is created in
"%APPDATA%\Roaming\WebTorrent".
- Put Electron crash files, and other electron files into the "Portable
Settings\Temp" folder instead of "%APPDATA%\Temp".
This gets rid of the light gray to dark gray background color change on
the main window at startup. Makes the window show slightly later, but
it's gray for less time. Doesn't affect overall startup time. Feels
less jank IMO.
From the Electron docs:
> While loading the page, the 'ready-to-show' event will be emitted
when renderer process has done drawing for the first time, showing
window after this event will have no visual flash.
Every require() that we do before the users sees UI reduces startup
time.
I used the following code (added to index.js) to log every require()
call in the main process:
```js
var Module = require('module')
var required = {}
Module.prototype.require = function (orig) {
return function (id) {
if (!required[id]) {
required[id] = true
console.log(`${id} (from ${this.filename})`)
}
return orig.apply(this, arguments)
}
}(Module.prototype.require)
```
From this I was able to learn that lots of modules were being required
that aren't actually used until later.
I also sent this related PR to eliminate another few require()s:
https://github.com/LinusU/node-application-config/pull/4
This increases startup time by 50ms.
We'll probably realize much bigger gains by following this same
procedure for the renderer process.
- Make State.save() always throttle calls -- since that's the common
case.
- Immediate saves are now the exception, with State.saveImmediate().
- The function is called State.save(), so the dispatch event should be
'stateSave'.
On my modern Macbook 12" I've run into "Saving state took too long.
Quitting.". We have users with spinning disk drives, so let's be a bit
more generous.
Detect the actual operating system CPU architecture. This is different
than `process.arch` which returns the architecture the binary was
compiled for.
This is just good info to have in the telemetry, but we're also sending
it in the update check so that eventually we can upgrade Windows 32-bit
apps to 64-bit, like Slack does.
Context:
https://github.com/feross/webtorrent-desktop/issues/873#issuecomment-247
722023
* Open multi-file torrents as playlists
* Add `repeat` and `shuffle` options to the player
* Autoplay first file in torrent
* replaces `pickFileToPlay` feature
* when reopening player, restores the most recently viewed file
* Add playlist navigation buttons to Windows thumbar
* Remove `repeat` and `shuffle` options
This reverts commit 9284122461.
* Play files in order they appear in torrent
* Clean up playlists code
