Community
Participate
Working Groups
CDT 2.0.0.200406140300 Eclipse RC2 IBM JRE 1.4.2 On a RedHat Linux machine, running off a local disk, I touch a header, and my build needs to rebuild 63 files. From the command-line, the build takes 5.6 seconds. From within CDT, touch the exact same header file, the build takes 2 minutes and 15 seconds! (Actually it's not the build, it's the console view; ps and "time make" indicate that the compile takes its usual short time.) I turned off all of the Error Parsers and Scanner Config but it made no noticeable difference. (I do not see the same trouble on Windows.)
Is this the J9 VM?
Assigning to Andrew for investigation
This was *not* the J9 VM, and was using May 25 IBM JRE. Caution: The problem may be non-trivial to reproduce. I was using CppTargetRTS as a project.
I'll snag this one while I wait for other responses to my last gating defect ... :-)
Brent, can you point me towards this project?
/home/bnicolle/cdt/big_projects/CppTargetRTS.psf
> I'll snag this one while I wait for other responses to my last gating > defect ... :-) Ok, but to let you on a little secret SWT/GTK is __really__ slow when comparing to SWT/Win32. I do not even want to start on SWT/motif. When building we do some processing(error parsers, scanner discovery, redirected to console view etc ...) So building from eclipse will __always__ be slower then on a terminal.
This is a serious problem, which reduces the usefulness of using CDT for compiling big projects on Linux.
I copy/pasted build output into a make.txt file to end up with 2000 lines of build output. my makefile was then "all: cat make.txt". Both windows and linux were comparably slow to output the build results (on the order of minutes for a build operation that took on the order of seconds). Turning off the error parsing and automated discovery parsing had no obvious affect on the time.
The problem is that we are flushing the stream between the process and the console on every read ( approx every 300 bytes on my test project ). And each flush creates a new Runnable to update the console UI. My initial changes which flush only when 1024 bytes make it through the stream reduces the time of a 5s shell build from 1m15s to 20s in the console. Also ErrorParserManager.checkLine(bool) is a little wastefull with the amount of string objects created, so we might be able to save a little time there. However, I'm not yet comfortable enough with these changes to put them in 2.0, so I'm changing the target milestone to 2.0.1
we are now exercising some restraint around how often we flush the pipes. fix commited to both head and 2.0 branch.
I've checked in some further improvements here for the build console (no more pipes, improved buffer mechanism on the ui side) some timings here with win32 and gtk show nice improvments with 'make -d', on a 1ghz athalon winxp, was ~20sec, now ~5sec, gtk (don't know the machine speed..) was 1min. 30sec, now 9-10secs using default console properties. I'll let it soak on the HEAD for now, if no problems are found I'll move to the branch.
I have problems using Sun's JRE Version 1.4.2 on Windows. It has got a flaw in the PipedInputStream: 1. Precondition: pipe is full. 2. WRITER writes to the pipe and "wait"s because the pipe is full. 3. READER reads from the pipe, but a "notify" to release the WRITER thread is missing. 4. After one second the WRITER's "wait" timeouts and the WRITER recognizes that the pipe is not full anymore and appends its data. Fix: PipedInputStream must call "notifyAll" at the end of a "read" operation. Although this is not eclipse's problem, I reopen because I think JRE 1.4.2 is quite common.
> I have problems using Sun's JRE Version 1.4.2 on Windows. It has got a flaw in > the PipedInputStream: Check the head, the pipes been removed. I doubt however that it will make it in the 2.0.1 branch because of the volume of the changes. But give the head a go, it probably fix your problem.
Looks good now!
changing state back...
Verified in 2.1 (Problem still exists in 2.0.2) Thanks, Dave.
