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

["Schaefer, Doug" <dschaefer@xxxxxxxxxxxx>]

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