Install Speed

0 views
Skip to first unread message

Tertulio Searcy

unread,
Aug 4, 2024, 4:37:51 PM8/4/24
to eperlanloe
Superhardware noob here. My wife and I were installing a game on our laptops last night, from an installation file (not a disc). The game takes up about 7.6GB of HD space. My laptop installed the game about twice as fast as hers. We both have Windows 7 64-bit OS and a 2.53GHz processor. The only difference I notice is the processor type: I have a i3 CPU M 380 @ 2.53GHz and she has 2 Duo CPU P8700 @ 2.53GHz. I thought her processor was really good.. what makes mine install software so much faster? Is there anything else that would affect installation speed?

Hard drive speed can make a huge difference. I recently install Microsoft Visual Studio on two laptops of similar specs, except for the hard drive. Installation on the 7200 rpm was far faster than on the 5400 rpm disk.


It's also worth remembering - as another answer mentioned - that just because both CPUs have the same clock speed it doesn't mean that they are both equally efficient at the same tasks, as the i3 is a newer generation of processor architecture than Core 2.


Hard drive speed - 7200 vs 5400 significantly affects installation time. I dont know of a tool to reveal RPM's of a drive, but you can look it up at the manufacturers web site. The following command, run from command prompt, will give you info for searching:


Hard drive fragmentation rate and available continuous space.. 7.8g is a pretty big file. It contains some number (from just one to thousands or more) of installation files. Your hard drive will need to work more if these files are in peices, or are spread out across the hard drive. You can analyze your fragmentation rate at command prompt:


When installing and uninstalling Windows Installer packages, or MSI files as they are called, the progress of the installation appears signifiantly slower than with other installation packages.


Much of the slowness of a Windows Installer session is due to its rollback capabilities. Firstly it creates a restore point prior to install or uninstall (provided system restore hasn't been disabled). Then it will back up all affected files and registry keys during both uninstall and install to ensure that the system can be restored to its original state should an error occur. Later versions of Windows Installer feature ways to disable some of this complexity and speed things up. See technical information below.


Another speed factor is that all components and features in the MSI will be registered in the registry. This involves quite a bit of overhead, but is necessary to achieve important corporate deployment and system administration benefits. No other deployment technologies feature this level of control.


Large MSI files with embedded source files may need a lot of time to extract its installer files to the temp folder. This can sometimes be the biggest bottleneck of all. It is recommended to run an admin install to extract the source files from such a package so that they appear side-by-side with the MSI file itself, eliminating the need to extract files locally on each machine and hence saving deployment time. Here is another article describing file extraction from MSI packages in simple terms.


UPDATE (Feb.2018): You can set a property called FASTOEM under very special circumstances (see linked content) in order to speed up deployment. I have never tried this, but it is well-worth a read. I doubt you will succeed using it effectively, but it might be worth a try.


Normal "costing" features a whole lot of feature, component, disk, and registry comparisons and calculations between what exists on the system and what is being installed. Most of this is rarely necessary in my opinion (disk space is generally plentiful on client PCs - and back in the reality of 2018 with smaller SD-disk the space issue might have resurfaced...), but it is obviously safer to let full costing run.


It is also possible to set the DISABLEROLLBACK property to disable rollback support in the MSI installer. I would strongly advise against using this unless you are staging a fresh PC. This is a special case when you can just start over if something fails. For a computer in real use I would not recommend enabling this property.


The irony is that disabling rollback will speed up things the most if you are running a huge update package that replaces lots of files, or any large uninstall (since an uninstall will move all removed files to a rollback area). It could be quite significant, but unsafe. You just set this property at the command line: msiexec.exe /I "D:\winzip112.msi" /QN MSIFASTINSTALL=3 DISABLEROLLBACK=1


And finally, as mentioned above in background information, run an administrative installation of the MSI file to extract files so that extraction doesn't happen locally on each machine. This assumes that you are on a rather fast network, and that file copy happens without too much delay. I suppose a high-latency wireless network could make things slower with small files extracted that have to be copied one by one. You run an admin install by simply passing a /a to the setup file:


Problem:

Multiple users around the world in different countries have incredible low download speeds, f.e. ISP Connection 120mbit, but MSFS2020 is downloading only with 1 to 20 mbit/s. The problem is there since release and is touching not only the download for the whole game or major updates, but also the ingame download through the marketplace.


Multiple users are reporting that at the same time, online speedtest and f.e Steam downloads have no problem and are giving the full download speed bandwith, so that it appears that its not a individual connection problem. Often the only thing which helps them is using a VPN and trying out different servers, sometimes even in the same country as they are located.


I managed to download the whole installation in about 2 hours with the max speed shown on some of the larger files at over 250MBps.

Subsequent updates all downloaded very quickly and in line with my expectations of a 300MBps connection.


The only thing which helps me is using a free VPN.

So for anyone who tried every step and is still suffering from download speeds like it is 2001 and doesnt want to pay for a VPN or give credit card informations:


1.) Google for ProtonVPN, register, download and install (absolutely no payment or credit card information is needed for the free servers from the USA, Nethlerlands and Japan

2.) Try every server from the USA, on Server 3, 4 and 8 I get at least 40 mbit, sometimes 70mbit (with a 120mbit connection), still not what I should get with my connection, but better than the 10mbit I get without VPN


I use Bell Fibe in NS with 1.5 Gbps service and have always suffered with slow downloads since the Tech Alpha. Max I get is 30Mbps until I connect a VPN. With a VPN connected, I can normally get 250-300Mbps.


The VPN connection also goes through your 2 routers, so its highly unlikely that its the 2 routers fault. Also basically everyone has slow download speed for msfs2020, the fault is on Asobo/Microsofts side.


Apart form the fact that I was getting good download speeds, then for a few months bad download speeds (maybe I messed up some settings) but now after making some adjustments to my network card settings and windows settings I am reliably getting close to my 300Mbps that my ISP provides.


I sent all my testing info through to Microsoft as a ticket. Most likely would only help those that are downloading from a specific server in Canada. Gave them everything I could so hopefully they use the data to trace things out.


I also suggested in my ticket to allow users to swap download endpoints from a list to allow users to potentially bypass hops that may be giving them issues. Much the same way we can change game servers, why not allow us to change download servers?


The nice thing about this --jobs argument is that it does in fact parallelize across CPU cores. So if we can find a way to pass that argument when running bundle install, we should be able to speed things up.


Brian joined BetterUp in 2017 as a Senior Full Stack Engineer. He lives in the Minneapolis area with his spouse and two sons. Brian is a lover of family time, hiking, biking, video games, and serial optimization.


I am trying to speed up the npm install during the build process phase. My package.json has the list of packages pretty much with locked revisions in it. I've also configured the cache directory using the command


However, on trying to install using npm install -g --cache, I find that this step isn't reducing the time to install by just loading the packages from cache as I would expect. In fact, I doubt if it's even using the local cache to look up packages first.


Use npm ci, which is available from npm version 5.7.0 (although I recommend 5.7.1 and upwards because of the broken release) - this requires package-lock.json to be present and it skips building your dependency tree off of your package.json file, respecting the already resolved dependency URLs in your lock file.


A very quickboost for your CI/CD envs (our build time was cut down to a quarter of the original!) and/or to make sure all your developers sit on the same versions of dependencies during development (without having to hard-code strict versions in your package.json file).


Use the --prefer-offline flag with your regular npm install / npm i. With this approach, you need to make sure you've cached your node_modules/ directory between builds (in a CI/CD environment). If it fails to find packages locally with the specific version, it falls back to the network safely.


pnpm uses hard links and symlinks to save one version of a module only ever once on a disk. When using npm or Yarn for example, if you have 100 projects using the same version of lodash, you will have 100 copies of lodash on disk. With pnpm, lodash will be saved in a single place on the disk and a hard link will put it into the node_modules where it should be installed.

3a8082e126
Reply all
Reply to author
Forward
0 new messages