View previous topic :: View next topic |
Author |
Message |
legion
Joined: 10 Oct 2007 Posts: 23
|
Extremely slow compilation on network drive |
Posted: Wed Oct 26, 2011 7:57 am |
|
|
Working with files on a network drive (ReadyNAS Duo, Raid configured) the compiler takes several minutes compared to a couple of seconds to compile typical sources. I don't think such a huge difference is down to the access time over the network as the files involved are all just a few kB and I don't normally notice any difference loading much larger files off the NAS or my local HD.
I have the NAS mapped on WinXP as drive Z: so all the paths look sensible e.g.
Z:\\Work\PIC\Project1\main.c
Does anyone know the reason/fix for this issue? Obviously I can work off my local drive but the Network server gives me security and access options not available on my PC. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9178 Location: Greensville,Ontario
|
|
Posted: Wed Oct 26, 2011 8:11 am |
|
|
just thinking out loud..
Could there be a lot of other 'action(traffic)' on the server that you're not aware of ?
Any chance some 'buffers' aren't large enough to transfer the data in one chunk?
Does this happen 'randomly' or at predefined time windows? Server could be doing something(updates,defrag,etc.) in the background, chewing up machine cycles.
Can't see any 'security or access options' that are better on a server compared to a local PC. I do all my work on the 'local drive',then upload the modified files to the server's HD for backup. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19383
|
|
Posted: Wed Oct 26, 2011 8:22 am |
|
|
I must say, I have not seen this as a problem. Compiling on a virtual PC, running inside a Mac, using a network drive for the files.
Is this with the Windows IDE, or using command line compilation?. What is the 'path' statement set for on the PC?. Some of the stuff (config files etc.), is looked for in the PATH, before the compiler looks in the defined locations in the project. I'd suspect some sort of issue with this setting resulting in a timeout, followed by finding the real files.....
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
legion
Joined: 10 Oct 2007 Posts: 23
|
|
Posted: Wed Oct 26, 2011 8:27 am |
|
|
temtronic wrote: | just thinking out loud..
Could there be a lot of other 'action(traffic)' on the server that you're not aware of ?
Any chance some 'buffers' aren't large enough to transfer the data in one chunk?
Does this happen 'randomly' or at predefined time windows? Server could be doing something(updates,defrag,etc.) in the background, chewing up machine cycles.
Can't see any 'security or access options' that are better on a server compared to a local PC. I do all my work on the 'local drive',then upload the modified files to the server's HD for backup. |
Hi, temtronic. Unfortunately it's *always* like it. Most of the time I'm the only one in the house using the Network anyway. This has been an ongoing issue for me for some years so I've been working round it as you suggest - using a local HD and backing-up regularly. However, I recently started using Dropbox so I could work collaboratively on a particular project and the Dropbox folder is on the NAS too. This is where I want my files! |
|
![](templates/subSilver/images/spacer.gif) |
legion
Joined: 10 Oct 2007 Posts: 23
|
|
Posted: Wed Oct 26, 2011 8:37 am |
|
|
Ttelmah, your setup sure makes mine seem trivial, so it ought to be resolvable!
My Path variable has "C:\PROGRA~1\PICC" in it, was that what you were expecting? I've used the Complier from the command line, from within MPLAB and ICEPIC and get the exact same result every time. (PCM 4.122) |
|
![](templates/subSilver/images/spacer.gif) |
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Wed Oct 26, 2011 9:28 am |
|
|
I've got this problem too. I've found it takes about 1minute or more to compile code that takes 10secs tops on a local drive. I've found that the slow down is at it worst when the compiler is writing the symbol tree (.tre) and the listing (.lst) to the network drive. I've disable writing the tree by unchecking Options ... Project Options ... Output Files ... Call tree file . That helps in my case. I haven't found a way to turn off the listing, though I use that pretty often, unlike the call tree, which I've looked at perhaps only a couple of times over the past year. Ironically, I spent a lot of time getting the Microchip C18 compiler to even produce me a listing from MPLAB!
My reason for using network drives is for souce backup reasons. There's little point in all the output and diagnostic stuff going there too. Only once I've fully debugged is there any need for me to write hex files, and hex files ONLY to a network drive for distribution and archive purposes.
I also don't like clogging up the network nor the server with this sort of nuisance traffic. It doesn't need to be there. The source needs to be there (though I'd MUCH prefer to be using a decent source control system and compiling from working copies on a local drive) but the other stuff is basically junk with a short shelf life in the sense that it's only valid until the next compilation.
The real problem as I see it is that you cannot redirect the intermediate and output files to a local drive. All the files, source, intermediates and output have to be in one directory. I've tried setting up the project on a local drive and pointing it to source on a network drive, but the IDE doesn't realise that the two are on different drives and it tries to construct a relative path to the source files, with disasterous consequences ;-( not to mention verrrrry loooong yet totally invalid path names.
RF Developer |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19383
|
|
Posted: Wed Oct 26, 2011 9:50 am |
|
|
Ah. So you have the compiler 'locally', and the data stored on the network?.
I installed the entire compiler on the network drive, so the path variable is talking to W: (not Z: for mine....).
I wonder if that is the difference. The compiler is on the same drive with the code (not the same directory).
I was thinking you might have had the PATH pointing to a local compiler directory that didn't actually exist.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
legion
Joined: 10 Oct 2007 Posts: 23
|
|
Posted: Wed Oct 26, 2011 9:59 am |
|
|
RF_Developer wrote: | I've got this problem too... |
RF_Developer, good to know it's not isolated to my setup. Let's hope there's a solution forthcoming. Perhaps this should go to support@ccsinfo.com
Ttelmah, I guess that's the essential difference - having the CCS program on the network drive. I'm a bit hesitant to try that (is it even possible on Windows? Says he showing his lack of PC savvy) |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
![](templates/subSilver/images/spacer.gif) |
legion
Joined: 10 Oct 2007 Posts: 23
|
|
Posted: Wed Oct 26, 2011 2:18 pm |
|
|
The same problem? In our case it's the CCS compiler that's taking the time to execute when called from the command line (or by another IDE such as RF Solutions ICEPIC) MPLAB isn't involved. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19383
|
|
Posted: Wed Oct 26, 2011 3:27 pm |
|
|
Interesting.....
It is better on the virtual PC in the Mac, than on a real one!.
It is also better with the compiler on the network drive.
Took a medium program, and compiled it locally on the virtual PC. 7.45 seconds 12000 lines. Same program, compiled it on the network machine with the compiler also on the network drive (as I normally run). 9.23 seconds. Then put the compiler locally, got slightly worse, to 12.43 seconds. Then ran up a W7 ultimate machine with similar hardware specs (I7, 12GB RAM), and tried this with the networked data 32.5 seconds!...
Ouch.
Also when browsing to find the file to compile, noticed that the actual update when you select a directory is slow from the Windows machine. Have never seen this from the Mac.
There is obviously something fundamentally wrong with the network handling, which is at least in part 'hidden' by using the virtual machine (it is the Mac that handles the networking here, the drive is seen as local by the virtual PC).
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
|