Re: KDevelop can't load project: "too large document"?

On 2017-12-12 11:10, René J.V. Bertin wrote:
> On Tuesday December 12 2017 10:24:46 Matthew Woehlke wrote:
>> Apparently you would need to actually configure KWIVER
> 
> That'd be the ultimate test, but I'm also not seeing similar sizes
> with other projects like KDevelop and QtWebKit.
...and the analysis I posted yesterday shows why; KWIVER has an
unusually high ratio of related statements, and a LOT of targets; more
than ten times as many as KDevelop (largely due to multiple utility
targets per test case). QtWebKit is actually a very poor test case for
the CMake server code model, as it has very few targets. I don't have
any to look at, but I would guess there are KF5 core libraries
(especially if any have extensive unit tests) that would be better test
cases.

> Your test project however gave me a 200.5Mb or so reply

Yep, that's about the right order of magnitude :-)... probably your
paths are about 40% longer than mine, accounting for it being larger for
you.

The key point is that both the test project and KWIVER have on the order
of a million related statement paths (KWIVER has 1018377, the test
project has 2310000, or a little over twice as many). In both cases,
these account for the majority of the code model. The test project may
be artificial, but the resulting code model structure is grossly
representative of KWIVER. (Far more homogeneous of course, but
comparable to KWIVER's average.)

Again, compare that to KDevelop, which had only 5746 related path
statements; that's more than two orders of magnitude difference!

> I checked with that test-project: initial import 54s, subsequent 
> imports under 4s (or under 25s when I delete the
> compile_commands.json file, forcing a reconfigure). BTW, I note that
> much of the time waiting for that reconfigure is in fact waiting for
> cmake to write the new build files to disk.
Huh...

I'm seeing 14s to dump the code model. This is without using KDevelop,
just feeding the commands to CMake server directly, and redirecting the
output to /dev/null. Most of this is spent building the code model;
using CMake master (which does not produce backtraces), it drops to
1.3s. I'm not seeing a significant difference between from-scratch and
subsequent runs. (I'm also using Ninja; with Makefiles, it jumps to
about 2.4s.)

What enormous files are being written to disk? My build.ninja is only
637 KiB...

-- 
Matthew