As for the speed, the bulk of the time spent is just copying files. However, there is also metadata written to the registry for each file (that's just how MSI does it), and the latest installer contains 37,148 files.
One solution I've been experimenting with is to put all our files into a single archive, in the MSI https://github.com/GPII/gpii-wix-installer/pull/54 - reduces the time greatly because only 1 file is "installed", and the hit of double de-compression isn't noticeable. Another On Thu, Mar 26, 2020 at 10:25 AM Javier Hernandez <j...@raisingthefloor.org> wrote: ... > On Wed, Mar 25, 2020 at 8:03 PM Steven Githens <st...@githens.org> wrote: ... >> In a Nutshell it sounds like the problems are: >> 1) It often hangs on uninstall >> 2) It takes a long time to run in both directions (install and uninstall) >> 3) The size of the installer is large, and the resulting install directories >> are quite large (about a gig and a half?) >> >> Am I missing anything? Our installer isn’t anymore complicated than a >> standard windows “Click Next 4 times” Installer, so I imagine if the above >> were resolved the installer itself would become a non-issue? >> >> I know stegru has already fixed several issues with 1 (though they may not >> be in a public build yet). > > > Looking forward to get to them. > #1 is in 1.3.4 (out now) >> >> As far as 2 and 3, I think some of them are due to us being on a very old >> version of Electron [2] > > > Electron has nothing to do with the installer slowness. > The biggest problem is that we have a lot of files under our node_modules > folder. Maybe we need to re-think the way we put things into the computer > when installing. Maybe, implementing a 2-step installation as lots of > software providers do these days would help. This is, installing the minimal > set of things and then download all the meat from the internet (this is, all > the relevant things in program files (x86)\morphic) as a zip file, unzipping > it, etc. That's what I've been thinking. The bulk of the time spent is just copying files. However, there is also metadata written to the registry for each file (that's just how MSI does it), and the latest installer contains 37,148 files. One solution I've been experimenting with is to put all our files into a single archive https://github.com/GPII/gpii-wix-installer/pull/54 - this has reduced the size (better compression with z7) and time (only 1 file is "installed"). As part of the updates work (GPII-4292), I'll be seeing what's needed to make this production ready. Other quick wins include de-duping infusion, and just running some disk analysis tool and pick out large useless things. We already trim out some things (see https://github.com/GPII/gpii-app/blob/master/provisioning/gpii-app.rcj) Max to the cheers, Steve Gr > Regarding WiX, yes, it's ugly, very, but nowadays it's the best thing we can > use in order for our installer to support things such as including merge > modules (filebeat, sharex and documorph) or performing custom tasks during > installation (i.e.: deal with the service) > It's also true that we can do some cleanup in gpii-wix-installer since there > are features that we don't use anymore, but these don't affect the size > and/or slowness when installing/uinstalling. > > As always, it's a matter of time and resources, you know that we're such a > small team working on many different things at a time and we all would love > to see this working better. > >> >> and perhaps needing to dedupe some of the node_modules that are being >> included multiple times. > > > Yes, that's one thing and we also need to ensure that we only ship production > packages - we don't need anything related to testing. This is what I > sometimes mentioned during our arch meetings, "we need to put our installer > on a diet" > In fact, yesterday I had a call with Kasper and he asked me what I would like > to see happening first and I replied "the installer needs a lot of love", we > both agreed that it is a top priority now that we want people to start taking > Morphic home. > > In addition to that, a few months ago I started creating some code to take > the installer creation logic out of gpii-app and have it in a custom repo > (https://github.com/GPII/gpii-windows-installer/pull/1/files) that we can > later on configure somehow to produce installers as new code gets into > gpii-app/master (that would make QA's life easier). That'd also allow other > people to create installers without having to know all the mumbo jumbo around > it (merge modules, siteconfig or service config files, etc). > I told Kasper that I'd try to get to that as soon as some of my top > priorities are out of the way and resume the work on it as I already had > uncommitted changes locally and was in the middle of refactoring it. As > always, any ideas or advice are welcome. > > >> >> I know Christopher has already done the initial research/legwork to get that >> upgrade rolling. > > > Yeah, regarding the electron update, looking forward to get to it. Dunno how > it's coming, but when I tried moving to electron 6 I had several problems > with some of our deps (see https://github.com/GPII/windows/pull/279/files and > https://github.com/GPII/gpii-app/pull/156/files), not sure how's the > situation nowadays, maybe Christopher can update us on it. > > Cheers to the max, > Javi > >> >> >> >> Moving forward with doing case studies and beta testing completely remotely, >> I’m hopeful that the above work resolves at least an initial brunt of these >> issues, and then any remaining ones can be triaged separately, such that >> installing/uninstalling in a teamviewer or windows helpdesk thing doesn’t >> take so long. >> >> Cheers, >> Steve >> >> >> >> [1] https://wixtoolset.org/ >> [2] Upgrading which I would suspect automagically fix some of the QSS >> performance issues >> _______________________________________________ >> Architecture mailing list >> Architecture@lists.gpii.net >> https://lists.gpii.net/mailman/listinfo/architecture > > _______________________________________________ > Architecture mailing list > Architecture@lists.gpii.net > https://lists.gpii.net/mailman/listinfo/architecture _______________________________________________ Architecture mailing list Architecture@lists.gpii.net https://lists.gpii.net/mailman/listinfo/architecture
