gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > make.exe takes long time to start

#137252 - gauauu - Thu Aug 09, 2007 2:42 pm

Quick question, if anyone knows.

I just set up devkitpro on a new computer (windows xp pro), checked out my code that I've been working on forever, but found out that on this new machine, make.exe takes about 10 or 15 seconds between when you launch it, and when it starts doing anything.

The same application with the same makefile works normally on other machines (including slower ones with less ram), but consistently takes forever to start on this particular machine. Once it gets going, it churns along at the normal rate.

Has anyone experienced this before? I'm wondering if there's some odd voodoo going on that is preventable? It's driving me crazy :)

Thanks!

#137257 - Dwedit - Thu Aug 09, 2007 4:35 pm

Is this the msys make or the cygwin make? Cygwin make might take a little bit of time to load if you aren't invoking it from within bash.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#137271 - gauauu - Thu Aug 09, 2007 7:21 pm

Nope, I just checked, and it's definitely msys.

#137274 - DiscoStew - Thu Aug 09, 2007 7:57 pm

Don't know if anyone else gets this, but I'm running VS 2003 for my dev environment, and when my cable internet connection is out, it takes much longer for my programs to compile.
_________________
DS - It's all about DiscoStew

#137280 - gauauu - Thu Aug 09, 2007 8:52 pm

I doubt that's it...I can't imagine why make would depend on a network connection, and my network was working when I tested it.....

#137288 - tepples - Thu Aug 09, 2007 10:15 pm

gauauu wrote:
I can't imagine why make would depend on a network connection

Do you have any shared folders? Do you have a software firewall on the PC that logs outgoing connections from each process?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#137322 - gauauu - Fri Aug 10, 2007 5:10 am

tepples wrote:

Do you have any shared folders?

nope
Quote:
Do you have a software firewall on the PC that logs outgoing connections from each process?

nope.

Should those even make a difference?

#137336 - naleksiev - Fri Aug 10, 2007 1:16 pm

I experience similar problem on pretty fast machine with XP when I try to compile with Programmers Notepad. Sometimes it took over 10 seconds to start the first task. The strange thing is that the make.exe process take 100% CPU during this 10 seconds. Sometimes I even need to kill the process. Then it will work with almost normal speed. I could compile 20-30 times and then it may happens again.

#137337 - drussell - Fri Aug 10, 2007 2:59 pm

I've never used MSYS, so I don't know how this would be configured, but when the make.exe process is starting up, maybe some directory in the path of the executable or parameters is taking a long time to check. Try moving the required directories to the beginning of the path so they are checked before the directories that are causing the delay.

#137381 - wintermute - Sat Aug 11, 2007 2:15 am

Check your anti-virus settings.

In some cases slow startup is related to on demand scanning which makes for very slow compiling. It's worth disabling the scan for the devkitARM folder if you can.

The other main cause is logitech webcams weirdly enough but this one usually causes make to crash. See this devkitPro FAQ entry for a fix.

[Fixed to use [url=] syntax so as not to widen the page -- MOD]
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#137821 - gauauu - Thu Aug 16, 2007 5:02 am

wintermute wrote:

In some cases slow startup is related to on demand scanning

Nope...this is turned off.
Quote:

The other main cause is logitech webcams weirdly enough but this one usually causes make to crash.


No webcam either.

Thanks for the suggestions, though...