Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Scanner configuration correctness for CDT 3.0 feature specs document available
Essentially, the command launcher will now push the output directly through to the ui console which will queue it to be displayed. Where before is had a java pipe in there which had significant delays when filling/emptying the pipe once if became full or emptied. see https://bugs.eclipse.org/bugs/show_bug.cgi?id=67718 for further details. 

Dave.

Ed Warnicke wrote:


Vlad,
Pardon my ignorance, but how was the "Extra layer of pipes through use of PipedOutputStrong and PipedInputStream objects in CommandLauncher.java" addressed? Does it leave situations where the command being run might be blocking waiting for Eclipse to empty a buffer? 

Ed
Vladimir Hirsl wrote:



Ed,
You are right in your analysis.
There were three factors (at least that I know of) that were slowing down the processing of output and error streams: 1. Extra layer of pipes through use of PipedOutputStream and PipedInputStream objects in CommandLauncher.java. This has already been addressed. 2. Error parsers that parse the build output for compilation and other errors. 
3. SC console parser that parses for SC affecting compiler options.
Certainly, we will be looking into decoupling SC discovery related processing from build as much as possible, either through background processing or some other way. 

Thanks,
Vmir



*Ed Warnicke <eaw@xxxxxxxxx>*
Sent by: cdt-dev-admin@xxxxxxxxxxx

11/08/2004 12:43 PM
Please respond to
cdt-dev
To 
    cdt-dev@xxxxxxxxxxx
cc
Subject Re: [cdt-dev] Scanner configuration correctness for CDT 3.0 feature specs document available 








Vlad,
   I've not had the chance to do a full overview of this proposal,
but a quick thought occured to me.

   You mention that
"It has been noticed that building medium sized projects with enabled
scanner configuration and error parsers causes almost two times longer
build times then building those projects outside of CDT. Parsing every
compiler command line from make build output for all scanner
configuration affecting options and consolidating them during the build
may prove to be too costly for large objects."

   Do we know why enabling scanner config increased build times?  I
have this sneaking suspicion
it has to do with the build program (make) writing it's output to a
pipe, which is being
read by CDT.  If CDT is slow parsing the output, it will also be slow
emptying the pipe, which means
the build program (make) will block waiting to write to the pipe. Might it not make more 
sense given this to have the build program (make) output to a file
(which won't block) and
have the SCD read and parse that file in the background at it's own
pace?  This (in principle)
would allow the build to proceed at it's natural rate with no
performance interference
from Eclipse.

   Please correct me if I'm misunderstanding the process (I admit, I've
not done due
diligence on looking into this).

Thoughts?

Ed

Vladimir Hirsl wrote:

>
> Hi All,
>
> My initial view of scanner configuration correctness requirements and
> design proposal can be found at:
> http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/cdt-home/developer/featurespec/3.0/scannerconf_correctness_3.0_fds.html?cvsroot=Tools_Project 
> <Feature%20specification%20document:>
>
> Your comments and suggestions are very welcome.
>
> Thanks,
> Vmir


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top