User forums > Nightly builds

The 17 May 2012 build (7966) is out.

<< < (13/15) > >>

cacb:

--- Quote from: oBFusCATed on June 03, 2012, 12:05:30 am ---If you where on unix you can have used the sort utility to sort both files :)
Is there a chance to try to bisect the nightly which is causing the slowness.
We have several nightlies in between 7452 and 7966.

--- End quote ---

Well, I have a Kubuntu machine in my network, so if you can tell me how use "the sort utility", I could try.

Regarding which nightly is slow, I already reported the following in April
http://forums.codeblocks.org/index.php/topic,16199.msg109543.html#msg109543

See also
http://forums.codeblocks.org/index.php/topic,16199.msg109568.html#msg109568
Where it is stated (by someone else) that 7918 is the first build with lags

oBFusCATed:
"cat myfile | sort > mysortedfile"

If the nightly is slow/lags in r7919 only, this should be fixed or you could work around it by disabling the todo plugin.

Slow building is caused by something else, so if you could pinpoint the revision where it started it could help.
Also are you sure that C::B correctly recognises the thread option?
Set it to something big and look in the task manager if you see many instances of cl.exe.
What happens if you tell it to build the code on a single processor?

cacb:
I have tested the "thread option" if you mean Global compiler settings | Build options | Number of processes for parallel builds
I get the expected number of cl.exe instances in Windows Task Manager.

If I set the number to 1, the build takes 5 minutes, i.e. slower than using the 2 processors I have. I get one cl.exe instance. If I set the number to 6, (3 times more than my 2 processors), I get 6 instances of cl.exe, the build then takes 2 minutes 42 seconds, about the same as when using 2 processors (no surprise).

So the problem is unrelated to the number of processor-setting. The problem is that, in 7966, something is preventing the compiler from using available CPU. During build with 7966, CPU use behaves like a yo-yo in Windows Task Manager, see attachment. The processors work at 100% for a while, then pauses for a significant period, where none of the cl.exe processes consume any CPU. This is totally different in 7452, where such pausing is not observed, compilation runs at full speed almost continuously. This is the reason why it is so much faster. The important question is what is causing the pausing in 7966, and I don't know the answer to that.

Another clue is perhaps this: When tweaking the setting Global compiler settings | Build options | Number of processes for parallel builds and press OK on 7452, the dialog disappears immediately. Again, it is different in 7966, where it takes almost 10 seconds from the time OK is pressed until the dialog disappears.

Btw. there is no antivirus or other "known nasties" running on the system. If that had been the problem, it shouldn't help to run an older C::B, but it does.

PS: Todo plugin (and many other plugins) disabled long time ago.

oBFusCATed:
So 7966 is slower than 7452 in single-thread mode?

Also please try to find the first release which is broken. Keep in mind that this issue is not related to the lag depicted in the old nighly's topic.
Also can you try with a clean settings?

And finally: If I understand correctly you see cl.exe doing nothing in the task manager? Or do you see periods of time where there are no cl.exe running?
The first one is not a problem of C::B, it is miss configuration. The second is a problem of C::B.

cacb:

--- Quote from: oBFusCATed on June 03, 2012, 03:24:45 pm ---So 7966 is slower than 7452 in single-thread mode?

Also please try to find the first release which is broken. Keep in mind that this issue is not related to the lag depicted in the old nighly's topic.
Also can you try with a clean settings?

And finally: If I understand correctly you see cl.exe doing nothing in the task manager? Or do you see periods of time where there are no cl.exe running?
The first one is not a problem of C::B, it is miss configuration. The second is a problem of C::B.

--- End quote ---

What kind of misconfiguration are you referring to? The configuration is exactly the same with the two C::B nightlies. I wish someone would believe my words.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version