Home » Language IDEs » C / C++ IDE (CDT) » Slow Console When Building
| Slow Console When Building [message #109834] |
Thu, 08 July 2004 11:32  |
Eclipse User |
|
|
|
Originally posted by: rolf.finecode.de-nospamremove.me
Hi,
I've CDT 2.0 running with Eclipse 3.0 on WinXP.
I have an external cmd (batch)-File which performs the build
(Project/Properties/C/C++ Make Project/Build command). The ouput is
captured by the console view. But, it's very slow. Every half second there
is a rush of about 1000 chars coming in, and then a half second nothing
agian, repeating this behaviour until all the output was captured. This
slows down the entire build process dramatically.
You can verify with a cmd-script which does:
dir
dir
....
dir
Any ideas, guys?
Daniel
--
dipl.-inf. cand.-phys. Daniel Rolf
finecode software / www.finecode.de
|
|
| | | | | | |
| Re: Slow Console When Building [message #110543 is a reply to message #110532] |
Tue, 13 July 2004 15:54  |
| Eclipse User |
|
|
|
Originally posted by: rolf.finecode.de-nospamremove.me
Yes, it's really a bug in the j2sdk1.4.2:
There is a wait(1000) in the PipedInputStream.receive, when the pipe is
full.
But, the PipedInputStream.read doesn't call notifyAll after it removed data
to resume the writer thread.
What now?
bye
Daniel
--
dipl.-inf. cand.-phys. Daniel Rolf
finecode software / www.finecode.de
"Daniel Rolf" <rolf@finecode.de-nospamremove.me> schrieb im Newsbeitrag
news:cd1dnj$rvt$1@eclipse.org...
> Same problem.
>
> I traced a little bit and found the following:
>
> - CommandLauncher: inputPipe.available is more or less exactly once a
> second 1024 bytes which equals to PipedInputStream.PIPE_SIZE on my jdk
> j2sdk1.4.2
> - ProcessClosure.ReaderThread: the writer.flush method sometimes needs one
> second to complete. It seems like that, if the pipe is full, this threads
> waits one second because it's not signaled that the pipe was drained. Yet,
> I looked in the JDK-source-code, and they're doing a good job using wait /
> notify stuff. I don't know what's wrong.
>
> Daniel
>
> --
> dipl.-inf. cand.-phys. Daniel Rolf
> finecode software / www.finecode.de
> "Andrew Niefer" <aniefer@ca.ibm.com> schrieb im Newsbeitrag
> news:cd1bel$nq1$1@eclipse.org...
>> In addition to the CommandLauncher, the fix for that bug also changed
>> org.eclipse.cdt.ui/src/org/eclipse/cdt/internal/ui/buildcons ole/BuildConsole
>> Partitioner.java
>>
>> -Andrew
>>
>> "Daniel Rolf" <rolf@finecode.de-nospamremove.me> wrote in message
>> news:cd14b6$av8$1@eclipse.org...
>>> I obtained the CommandLauncher from the CVS and replace the one in the
>>> eclipse\plugins\org.eclipse.cdt.core_2.0.0\cdtcore.jar with the compiled
>>> class.
>>>
>>> The problem still persists. Nothing seemed to have changed.
>>>
>>> bye
>>>
>>> Daniel
>>>
>>> --
>>> dipl.-inf. cand.-phys. Daniel Rolf
>>> finecode software / www.finecode.de
>>> "Johan Walles" <johan.nosp@m.appeal.se> schrieb im Newsbeitrag
>>> news:ccm06l$fa5$1@eclipse.org...
>>> > As I said, the Bugzilla is your friend.
>>> >
>>> > If you'd read the last two comments (at the bottom of
>>> > "https://bugs.eclipse.org/bugs/show_bug.cgi?id=67718") you'd have
>>> > seen:
>>> >
>>> > "
>>> > 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
>>> > "
>>> >
>>> > and
>>> >
>>> > "
>>> > fix commited to both head and 2.0 branch.
>>> > "
>>> >
>>> > This means you can either download the CVS version of the 2.0 CDT
>>> > stream
>>> > and build it yourself or wait for 2.0.1 to be released.
>>> >
>>> > //Johan
>>> >
>>> > Daniel Rolf wrote:
>>> >> I see. How can I obtain a fixed version?
>>> >>
>>> >> Daniel
>>>
>>>
>>
>>
>
>
|
|
|
| Re: Slow Console When Building [message #110566 is a reply to message #110543] |
Tue, 13 July 2004 17:05 |
| Eclipse User |
|
|
|
You could try changing the command launcher to use a bigger pipe. Check out
the BiggerPipedInputStream at
http://www.cafeaulait.org/books/javaio/errata/08.html as an example. I
thought this was a bit of a hack and responsible flushing seemed to fix the
problem for me which is why I didn't make that change.
-Andrew
"Daniel Rolf" <rolf@finecode.de-nospamremove.me> wrote in message
news:cd1ej6$t8c$1@eclipse.org...
> Yes, it's really a bug in the j2sdk1.4.2:
>
> There is a wait(1000) in the PipedInputStream.receive, when the pipe is
> full.
> But, the PipedInputStream.read doesn't call notifyAll after it removed
data
> to resume the writer thread.
>
> What now?
>
> bye
>
> Daniel
>
> --
> dipl.-inf. cand.-phys. Daniel Rolf
> finecode software / www.finecode.de
> "Daniel Rolf" <rolf@finecode.de-nospamremove.me> schrieb im Newsbeitrag
> news:cd1dnj$rvt$1@eclipse.org...
> > Same problem.
> >
> > I traced a little bit and found the following:
> >
> > - CommandLauncher: inputPipe.available is more or less exactly once a
> > second 1024 bytes which equals to PipedInputStream.PIPE_SIZE on my jdk
> > j2sdk1.4.2
> > - ProcessClosure.ReaderThread: the writer.flush method sometimes needs
one
> > second to complete. It seems like that, if the pipe is full, this
threads
> > waits one second because it's not signaled that the pipe was drained.
Yet,
> > I looked in the JDK-source-code, and they're doing a good job using wait
/
> > notify stuff. I don't know what's wrong.
> >
> > Daniel
> >
> > --
> > dipl.-inf. cand.-phys. Daniel Rolf
> > finecode software / www.finecode.de
> > "Andrew Niefer" <aniefer@ca.ibm.com> schrieb im Newsbeitrag
> > news:cd1bel$nq1$1@eclipse.org...
> >> In addition to the CommandLauncher, the fix for that bug also changed
> >>
org.eclipse.cdt.ui/src/org/eclipse/cdt/internal/ui/buildcons ole/BuildConsole
> >> Partitioner.java
> >>
> >> -Andrew
> >>
> >> "Daniel Rolf" <rolf@finecode.de-nospamremove.me> wrote in message
> >> news:cd14b6$av8$1@eclipse.org...
> >>> I obtained the CommandLauncher from the CVS and replace the one in the
> >>> eclipse\plugins\org.eclipse.cdt.core_2.0.0\cdtcore.jar with the
compiled
> >>> class.
> >>>
> >>> The problem still persists. Nothing seemed to have changed.
> >>>
> >>> bye
> >>>
> >>> Daniel
> >>>
> >>> --
> >>> dipl.-inf. cand.-phys. Daniel Rolf
> >>> finecode software / www.finecode.de
> >>> "Johan Walles" <johan.nosp@m.appeal.se> schrieb im Newsbeitrag
> >>> news:ccm06l$fa5$1@eclipse.org...
> >>> > As I said, the Bugzilla is your friend.
> >>> >
> >>> > If you'd read the last two comments (at the bottom of
> >>> > "https://bugs.eclipse.org/bugs/show_bug.cgi?id=67718") you'd have
> >>> > seen:
> >>> >
> >>> > "
> >>> > 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
> >>> > "
> >>> >
> >>> > and
> >>> >
> >>> > "
> >>> > fix commited to both head and 2.0 branch.
> >>> > "
> >>> >
> >>> > This means you can either download the CVS version of the 2.0 CDT
> >>> > stream
> >>> > and build it yourself or wait for 2.0.1 to be released.
> >>> >
> >>> > //Johan
> >>> >
> >>> > Daniel Rolf wrote:
> >>> >> I see. How can I obtain a fixed version?
> >>> >>
> >>> >> Daniel
> >>>
> >>>
> >>
> >>
> >
> >
>
>
|
|
|
| Re: Slow Console When Building [message #110690 is a reply to message #110566] |
Wed, 14 July 2004 12:51 |
| Eclipse User |
|
|
|
Originally posted by: rolf.finecode.de-nospamremove.me
I filed the bug to Sun. But, should we not provide a general solution, maybe
we roll our own PipedInputStream. Because, Sun is not likely to fix this bug
very soon... After all, the impl. has not changed since V1.32 January 2003.
Moreover, the Sun-JDK is quite commonly used. Can you check your JDK for the
bug (or mail me the source file)? I looked at the Kaffee-VM, it looks
better, but not very efficient...
A simple workaround is to derive from PipedInputStream, to override "read"
and to call notifyAll after calling "super.read".
bye
Daniel
--
dipl.-inf. cand.-phys. Daniel Rolf
finecode software / www.finecode.de
"Andrew Niefer" <aniefer@ca.ibm.com> schrieb im Newsbeitrag
news:cd1ikr$48b$1@eclipse.org...
> You could try changing the command launcher to use a bigger pipe. Check
> out
> the BiggerPipedInputStream at
> http://www.cafeaulait.org/books/javaio/errata/08.html as an example. I
> thought this was a bit of a hack and responsible flushing seemed to fix
> the
> problem for me which is why I didn't make that change.
>
> -Andrew
>
> "Daniel Rolf" <rolf@finecode.de-nospamremove.me> wrote in message
> news:cd1ej6$t8c$1@eclipse.org...
>> Yes, it's really a bug in the j2sdk1.4.2:
>>
>> There is a wait(1000) in the PipedInputStream.receive, when the pipe is
>> full.
>> But, the PipedInputStream.read doesn't call notifyAll after it removed
> data
>> to resume the writer thread.
>>
>> What now?
>>
>> bye
>>
>> Daniel
>>
>> --
>> dipl.-inf. cand.-phys. Daniel Rolf
>> finecode software / www.finecode.de
>> "Daniel Rolf" <rolf@finecode.de-nospamremove.me> schrieb im Newsbeitrag
>> news:cd1dnj$rvt$1@eclipse.org...
>> > Same problem.
>> >
>> > I traced a little bit and found the following:
>> >
>> > - CommandLauncher: inputPipe.available is more or less exactly once a
>> > second 1024 bytes which equals to PipedInputStream.PIPE_SIZE on my jdk
>> > j2sdk1.4.2
>> > - ProcessClosure.ReaderThread: the writer.flush method sometimes needs
> one
>> > second to complete. It seems like that, if the pipe is full, this
> threads
>> > waits one second because it's not signaled that the pipe was drained.
> Yet,
>> > I looked in the JDK-source-code, and they're doing a good job using
>> > wait
> /
>> > notify stuff. I don't know what's wrong.
>> >
>> > Daniel
>> >
>> > --
>> > dipl.-inf. cand.-phys. Daniel Rolf
>> > finecode software / www.finecode.de
>> > "Andrew Niefer" <aniefer@ca.ibm.com> schrieb im Newsbeitrag
>> > news:cd1bel$nq1$1@eclipse.org...
>> >> In addition to the CommandLauncher, the fix for that bug also changed
>> >>
> org.eclipse.cdt.ui/src/org/eclipse/cdt/internal/ui/buildcons ole/BuildConsole
>> >> Partitioner.java
>> >>
>> >> -Andrew
>> >>
>> >> "Daniel Rolf" <rolf@finecode.de-nospamremove.me> wrote in message
>> >> news:cd14b6$av8$1@eclipse.org...
>> >>> I obtained the CommandLauncher from the CVS and replace the one in
>> >>> the
>> >>> eclipse\plugins\org.eclipse.cdt.core_2.0.0\cdtcore.jar with the
> compiled
>> >>> class.
>> >>>
>> >>> The problem still persists. Nothing seemed to have changed.
>> >>>
>> >>> bye
>> >>>
>> >>> Daniel
>> >>>
>> >>> --
>> >>> dipl.-inf. cand.-phys. Daniel Rolf
>> >>> finecode software / www.finecode.de
>> >>> "Johan Walles" <johan.nosp@m.appeal.se> schrieb im Newsbeitrag
>> >>> news:ccm06l$fa5$1@eclipse.org...
>> >>> > As I said, the Bugzilla is your friend.
>> >>> >
>> >>> > If you'd read the last two comments (at the bottom of
>> >>> > "https://bugs.eclipse.org/bugs/show_bug.cgi?id=67718") you'd have
>> >>> > seen:
>> >>> >
>> >>> > "
>> >>> > 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
>> >>> > "
>> >>> >
>> >>> > and
>> >>> >
>> >>> > "
>> >>> > fix commited to both head and 2.0 branch.
>> >>> > "
>> >>> >
>> >>> > This means you can either download the CVS version of the 2.0 CDT
>> >>> > stream
>> >>> > and build it yourself or wait for 2.0.1 to be released.
>> >>> >
>> >>> > //Johan
>> >>> >
>> >>> > Daniel Rolf wrote:
>> >>> >> I see. How can I obtain a fixed version?
>> >>> >>
>> >>> >> Daniel
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>
>
|
|
|
Goto Forum:
Current Time: Thu May 22 19:22:17 EDT 2025
Powered by FUDForum. Page generated in 0.03031 seconds |
Home