Re: [cdt-dev] Scanner configuration correctness for CDT 3.0 feature spec

[Vladimir Hirsl <vhirsl@xxxxxxxxxx>]

Ed,
After some investigation I have realized
that putting SCD in another background job parallel with the build would
not yield any improvements, since build is already a background job, so
the two would share processor time evenly. The reason is because Eclipse
jobs all operate from same priority threads, the only parameter that can
be specified is scheduling policy, but not the thread priority. So once
job is sheduled to run it will not release processor until it is blocked.


The upside is, since build is on background
thread already, that user does not need to wait for build to finish to
start using CDT. However, to have a project properly set-up, scanner configuration
discovery, as a part of the build, has to finish.

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