Re: [cdt-core-dev] Build on Windows

[David Inglis <dinglis@xxxxxxx>]

Schaefer, Doug wrote:
> Great question.  From what I've seen so far, there is something else
> throttling the Console, and my guess, it's the performance of the replace()
> method on the document.  But I need to investigate this a little more.

Very well could be, I have looked at the Console in the debug plugin and see
that they use a Document interface, does this console have performance problems on
the various platforms? If not, it might be a good reference to see what they did
to speed things up (possible the ITextStore they use?).

> Could the creator of this code comment more (before we go and wreck it ;-)?
>
> Thanks,
> Doug Schaefer
> Senior Staff Software Engineer
> Rational - the software development company
> Ottawa (Kanata), Ontario, Canada
>
>
> -----Original Message-----
> From: Chris McKillop [mailto:cdm@xxxxxxx] 
> Sent: February 17, 2003 9:59 AM
> To: cdt-core-dev@xxxxxxxxxxx
> Subject: Re: [cdt-core-dev] Build on Windows
>
>
> Any reason why this output window is using an IDocument interface (and, in
> turn, the StyledText widget)?  Might be a whole lot faster if we just used
> a raw SWT Text widget and appended the text to it's buffer.
>
>     chris
>
>
> On Mon, Feb 17, 2003 at 04:31:01PM -0500, Schaefer, Doug wrote:
>
> > Thanks, Alain.  I removed the buffering and Windows was fine, although
>
> slow,
>
> > especially as the document got bigger (BTW, great test case = include the
> > real version of windows.h with the gcc compiler ;-).
> >
> > I'll go try it on GTK right now and will let you know.  (Although my I
>
> have
>
> > a feeling it is going to be brutal).
> >
> > Doug Schaefer
> > Senior Staff Software Engineer
> > Rational - the software development company
> > Ottawa (Kanata), Ontario, Canada
> >
> > -----Original Message-----
> > From: Alain Magloire [mailto:alain@xxxxxxx] 
> > Sent: Monday, February 17, 2003 4:01 PM
> > To: cdt-core-dev@xxxxxxxxxxx
> > Subject: Re: [cdt-core-dev] Build on Windows
> >
> >
> > > Yup, that's pretty much exactly what I'm seeing.  For small builds with
> no
>
> > > errors, I'd prefer to see something while I'm waiting.  At 512
> characters,
>
> > > it could be a few files into the build before I see anything.
> > >
> > > I can see that if you were asyncExec'ing each line, you'd have problems
> > > since this can end up queing up quite a few Runnables.  However, I
> notice
>
> > > that there is a syncExec there right now.  Did this not solve the
> problem
>
> > on
> >
> > > its own?  This should theoretically let the pipes fill up while waiting
> >
> > for
> >
> > > the UI to update.
> >
> > IIRC.
> > Yes the syncExec() should have fix it, but when doing testing on
>
> Eclipse/GTK
>
> > it was still slow ... very slow, since the write() affected directly
> > the IDocument, so to help improve, the bufferring was added.
> > However on Windows, things were fine, I do not remember
> > on Motif but I think it was acceptable.
> >
> > The Eclipse/gtk was our benchmark by being the slowest platform.
> >
> >
> > > As another solution, I was thinking of using a sync object and making
> sure
>
> > > only one Runnable got enqueued at a time.  Thoughts?
> >
> > Remove the buffering and see how it behaves for you.
> > Maybe the 2.1/SWT/GTK improves the IDocument/fonts problems.
> >
> >
> > _______________________________________________
> > cdt-core-dev mailing list
> > cdt-core-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/cdt-core-dev
> > _______________________________________________
> > cdt-core-dev mailing list
> > cdt-core-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/cdt-core-dev