[resolved] Hello_world compiles very slowly on Windows 7


#1

Compiling (rustc main.rs) hello world program from The Book takes about 90 seconds.

I am on 32 bit Windows 7 and rustc 1.25.0. I have used C++, java, and python in the past and didn’t have noticeable problem with speed.

I recently tried to install Go and had the similar kind of problem but, for Go, even go --version and go clean (delete object files) took about 20 seconds and 50 seconds, respectively. By contrast, rustc --version brings up the result instantly. Also, I recently compiled a few C++ files with a makefile and didn’t notice any problem with speed.

I am very interested in this language and would like to make 2d games with it. I am trying to get back into programming. I would appreciate any suggestion on things to try. Thanks.


#2

Wow. Indeed, something looks really wrong here, and the fact that you had similar issues with Go suggests that the issue lies somewhere in your system’s configuration (hardware, OS, background software…).

Can you go to Task Manager > Performance tab > Resource Monitor, and take a screenshot of the system activity graphs when your system is in an idle state and another when it is performing some rustc or go work? I’m very curious about what the system is doing during these 20~90 seconds.

Another question is, what is your disk/filesystem layout? Do you use the standard NTFS C:/ partition on a single drive, or something more peculiar?

And third question, are you running rustc natively or through some sort of Unix emulation layer like cygwin?


#3

What can also be useful: Resource Monitor has a “Disk” tab which will tell you if something is driving your disks really hard. Doesn’t seem likely to be the cause, but you might as well eliminate it as a potential issue while you’re at it.


#4

Well, there are just so many things that can go wrong with disks:

  • Some background program is hammering them (e.g. AV software, Windows Update…)
  • They are almost full and the OS is struggling to find room for new data
  • They are fragmented and the OS/hardware is struggling to read/write existing data
  • The hardware is failing spuriously, and the OS does not clearly tell you about it (e.g. some of my SSDs will strangely hang every other month, which causes ~1s system freezes until the OS decides to reset them, and on Linux that’s only reported via dmesg…)

But although in my personal experience, such spectacularly bad performance has always originated from IO issues, we have no clear proof that this is the problem here yet, so I’m waiting for more data first before investigating this track further :slight_smile:


#5

I’ve had serious performance issues with Rust when the disk is being hammered. Presumably, it’s all the little files Cargo and Rust write out during compilation. But that’s usually because of lots of dependencies; a simple Hello World shouldn’t have that problem.


#6

Thanks for the reply.

I was taking pictures of the performance graphs and realized that compilation finishes every time I open a task manager. Moreover, I can compile in a second with task manager open.

This used to be a dual boot windows/linux but long time ago linux failed to boot after kernel update and since then only using the windows side.

I installed rust from the installer. Does that mean it is run natively?


#7

Thanks for the reply. I realized that, strangely, compilation finishes when I open the task manager or when it is already open. Here’s a screenshot of “Disk” tab right after compilation has finished:


#8

Now, this is some strange stuff. Well, on the positive side, at least you have a workaround for compiling Rust code quickly for the time being :stuck_out_tongue:

Can you try to boot your computer in safe mode and see if rustc runs quickly in this configuration? I’m not sure if Windows safe mode has everything needed for rustc to run, but if so it will test my spontaneous hypothesis of background software “hiding itself” when the task manager is on (malware perhaps?).

Yes it does :slight_smile: So no performance problem to investigate in this direction. And the presence of a Linux partition that is not accessed by Windows should not affect its performance either.


#9
  • I don’t have an AV software and Windows Update is turned off.
  • In Computer, it says C: drive is 116GB free of 156GB, which seems to mean disk is not full.
  • In Disk Defragmenter it says “Scheduled defragmentation is turned on”, and “Run at 1 AM every Wednesday”. When I press “Analyze” it’s stopped at 19% for a while now. (I wasn’t even aware of the concept of defragmentation before you mentioned it.)

Here’s a screenshot of Resource Monitor when Palemoon browser is open with only this tab:


#10

Yes, in safe mode rustc compiles quickly without Task Manager.

Edit:

After exiting safe mode and booting normally I got a system error from BrCtrlCntr.exe: “The program can’t start because VCOMP100.DLL is missing …” When installing rust I installed newer C++ build tool so I removed an older Visual C++ via Control Panel later. I wonder if that was a bad idea.


#11

EDIT: Sorry, forget about this post, I was looking at the wrong plot in the system resource monitor (CPU frequency, not activity).


#12

That would be (a part of) your printer driver. Maybe you accidentally deleted the visual C++ runtime, which is distinct from the Visual C++ development tools, and contains files which are required for software compiled using VC++ to run. If that is the case, the easiest fix will probably be to uninstall and reinstall your printer driver, which should include the proper version of the runtime.


#13

EDIT: Sorry, forget about this post, I was looking at the wrong plot in the system resource monitor (CPU frequency, not activity).


#14

I moved all the files on Desktop into a new directory in %HOME%. It didn’t affect rustc.

Printer I don’t use so that’s fine. I should have web-searched the exe file before posting.


#15

Sorry, that advice was misplaced. I was looking at the wrong plot in the resource monitor and thought you were at 100% CPU usage all the time, when that was not the case.


#16

No problem. I guess I need a way to find out if there’s a malware hiding from the Task Manager.


#17

Just to make sure: Have you ruled out incremental compilation as a possible explanation for it completing quickly in safe mode and etc.? Normally when compiling something you have already built, it will finish quickly.

The easiest way to rule this out is to delete the target directory before building in safe mode, to see whether it still completes quickly.


#18

One possible option to investigate this track in more depth would be to use another software than the Windows Task Manager for monitoring process activity, such as SysInternals’ Process Explorer. If that is truly malware trying to be clever, it can’t possibly know or care about every Windows system monitoring tool in existence :slight_smile:


#19

Thanks for reply. In your reply, what is the target directory? When Task Manager is not around, rustc compiles very slowly, even after doing it immediately before. I will try deleting pdb and exe files before compiling in safe mode.


#20

Okay, that is interesting, considering that it can’t be doing very much other than checking file timestamps. (and maybe cargo makes some web queries. Not sure. I don’t think it should need to…)

It’s not really necessary to try this test then (since the above quote already rules this out this explanation), but I’ll mention this anyways: The target directory is what holds the built binaries and executables. On unix, it appears as a directory named target inside the folder with your Cargo.toml file. I’m not sure what happens on Windows. Perhaps I have misled you and it doesn’t even exist!