Generating installer too slow

[mzmousa]

How long should generating the installer take? My full nupkg is ~80 MB, and generating the setup.exe, and -full.nupkg files takes 5-10 minutes. Is this normal? What are ways of making this process faster?

[MarshallOfSound]

@mzmousa That's perfectly normal as far as I am aware. My build process (including dependency installation and cloning of the repo) takes anywhere from 9 - 18 minutes

[develar]

@MarshallOfSound It is not normal and fixed in the electron-builder. Delta package is still not fixed and slow. electron-userland/electron-builder#351

[MarshallOfSound]

@develar In terms of the question and this library, the times mentioned are normal I.e. Not different to the average time any user of this library would achieve.

If it turns out there is an underlying issue that makes the zip process slow for all users that is a separate issue to this question.

Is @paulcbetts or @kevinsawicki aware of the underlying zip issue?

[develar]

the times mentioned are normal

No. 5-10 minutes (includes tests) it is normal if you have heavy-weight tests (e.g. electron-builder tests — we build a lot of apps during test). Otherwise it is unacceptable time. Indicating that something is wrong in your tools/setup. Electron app on slow windows machine — Appveyor CI server — ~ 2 min 55 sec. Again — delta package is not fixed and it is very slow (4 minutes to build one delta file on OS X machine).

aware of the underlying zip issue?

Yes. Decision — it is ok.

[MarshallOfSound]

@develar I think you are missing the point of my answer. The question was "is it normal"

Definition of normal:

conforming to a standard; usual, typical, or expected.

That time is usual, typical and expected. Hence normal....

Yes. Decision — it is ok.

Not much I can say to that, if there is in fact a significant speed gain to be had from fixing this issue I don't see why it can't be an open triaged issue on Squirrel.Windows for someone to tackle one day. But yeah, that's up for them to decide

[develar]

That time is usual, typical and expected. Hence normal....

Hmmm... Why? 5-10 minutes is not expected time. Hey! My project contains 67K java files and full rebuild takes only 5 minutes. If default Squirrel.Windows pack impl tooks so much time and CPU, I have the only question, sorry.

can't be an open triaged issue on Squirrel.Windows for someone to tackle one day

My plan: when my changes will be stabilised, I will attempt to open another PR (#77).

[MarshallOfSound]

@develar I think this went off on a tangent and now we are discussing the definition of normal so I'll just end this with a TLDR

TLDR:
When using electron-winstaller it is typical to get a build time anywhere from 5 - 10 minutes depending on hardware. Although typical this is not optimal.

That said, as is mentioned in that PR you referenced it is virtually impossible to test the long reaching side affects of making core changed to this tool. For instance a single bugfix to handle spaces in executable names caused my app to be sent out to a few hundred users in a matter of minutes before I detected a bug due to an upgrade path from 2.0 -> 2.3 and this resulted in a bricked app (no way to update as it won't start).

Testing all possible scenarios and files you would want to package is a massive task and personally I'll take the 10 minute build time and a guarantee that things will work over a 30 second build time with possible flakiness. This is why I've actually locked in our electron-winstaller dependency to be only 2.2.0 and we will stick with that as long as we can.

[anaisbetts]

Testing all possible scenarios and files you would want to package is a massive task and personally I'll take the 10 minute build time and a guarantee that things will work over a 30 second build time with possible flakiness.

^^^ A Thousand Times This. I'm all for making builds fast, but not at the expense of possibly stranding users or breaking something, which is why I rejected the previous PR (not because I have like, a fetish for slow software or something)

[MarshallOfSound]

Closing this out as we seem to be in agreement that this is Expected(tm)