Poor performance on large projects

[GoogleCodeExporter]

1. Run cppcheck on a large project

It just takes too much time. With such performances, I'd rather launch it
on a server.

It seems that a new cppcheck process is forked for each source code, so
that there is a big overhead.

And it would be nice to be able to perform a remote launch, or at least to
be able to give a result file as input.

Original issue reported on code.google.com by mathieu....@gmail.com on 5 May 2010 at 9:00

[GoogleCodeExporter]

That's already on top of my list. Actually I already have a working prototype 
which
uses one cppcheck process for all files of a project. That should push the
performance, especially for large projects. 
But I don't understand, what you mean by remote launch. You can already run 
cppcheck
in background. I also don't get your other option with the result file as input.
Whose result as input for what?

Original comment by konra...@gmx.de on 5 May 2010 at 4:43

• Changed state: Started
• Added labels: Milestone-0.9.6

[GoogleCodeExporter]

If you are using Eclipse with Windows, the "-j" option is not available, and the
static analysis is even slower. But if your workspace is on a network file 
system,
you can access it from a linux server, which has many cores and can speed up a 
lot
your builds (I actually use that 'remote build' a lot) or any other heavy 
operation
(static analysis for ex.).

I don't know what will be the development cost of such a solution, so that an 
easier
solution could be to manually launch cppcheck on the server, redirect the 
output in a
file, and give this file to the cppcheclipse plugin on the desktop PC.

Original comment by mathieu....@gmail.com on 5 May 2010 at 6:00

[GoogleCodeExporter]

Regarding the  -j option not available on Windows, this is a known bug in 
cppcheck
(http://sourceforge.net/apps/trac/cppcheck/ticket/648). Feel free to fix it ;-) 
Remotely launching cppcheck via cppcheclipse and waiting for the response via 
network
is nothing I will implement in the near future, since only very few people were 
can
use it and it's hard to test. But if anyone wants to contribute some source 
code to
implement this feature, I would be happy to integrate it.

Original comment by konra...@gmx.de on 5 May 2010 at 9:47

[GoogleCodeExporter]

I know it sounds complicated.

Let me explain how I perform a remote build:

In the C/C++ Build part of my project properties, I indicate the following 
"Build
command":

C:\plink\plink.exe -i Z:\private.ppk user@server cd directory ; make  -j

That performs a build on the server, and the output is redirected to eclipse, 
so that
eventual make warning/errors are correctly parsed and added to the "Problems" 
view!

So, a solution to perform the static analysis remotely would be to give a way 
to edit
the "cppcheclipse command".

It seems actually impossible to do that since the cppcheclipse plugin is 
verifying
the "cppcheck binary path".

Original comment by mathieu....@gmail.com on 6 May 2010 at 7:42

[GoogleCodeExporter]

This issue was closed by revision r177.

Original comment by konra...@gmx.de on 15 May 2010 at 12:53

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by konra...@gmx.de on 16 May 2010 at 11:51

• Changed state: Verified

[GoogleCodeExporter]

FYI, I found a way to integrate my remote stuff into eclipse.
I did the following configuration:

1/ install this generic error parser

http://www.embeddedautomotive.de/products/embedded-development-tools/eclipse-ide
/regular-expression-error-parser-for-cdt.html

2/ add a build configuration with the following build command

C:\plink\plink.exe -i ppkfile user@server cd projectdir ; cppcheck . --force
--enable=all --template  '{file}:{line}: {severity}: {message}'

(for a local cppcheck: <path to cppcheck>\cppcheck.exe <path to project dir> 
--force
--enable=all --template  '{file}:{line}: {severity}: {message}')

3/ add the RegEx error parser to the cppcheck build configuration

4/ build => errors are parsed

All errors are not correctly read, but simple rules can be added to the error 
parser.

Original comment by mathieu....@gmail.com on 27 May 2010 at 8:59