KDevelop 5 too slow?

René J.V. Bertin rjvbertin at gmail.com
Mon May 29 12:05:21 BST 2017

On Monday May 29 2017 11:43:42 Milian Wolff wrote:

> > the time the CPU spends waiting for I/O operations. Would a CPU profiler
> > exclude the CPU cycles spent on I/O just because it's I/O?
> No, a kernel switches out a process that is waiting on something, i.e. 

Wording... I meant CPU cycles spent by the process. Even when pumping data from a file into a buffer the CPU must be spending *some* cycles in the process itself, no?

> cycles, these will be attributed to whatever other process gets switched in 
> (which may also be a pseudo-"idle"-process).

That shows up as "kernel_task" on Mac.

> > So I ought to do this kind of profiling with only a single document open?
> > That should actually be more representative of what happens when you make
> > changes to the current document.
> I don't know what exactly you are trying to profile.

I was trying to provide data that would help understand the kind of issue the OP complains about. Now, if that can also be done on Linux with the exact builds that show the issue (= without running a special build) then I don't think my help is indispensable.

> > FWIW, it's still a bit confusing. The current document is also parsed in the
> > background, so what the option in the settings controls is actually the
> > number of threads to use for parsing "background documents"?
> The N in the N + 1 above.

I guess that's what I mean: you think you're allocating N threads to something CPU intensive and you're actually allowing N+1 threads. The settings dialog in question could be reworded to reflect that, or else show N-1 in the spinner.

> I mean it's a waste of time to muse about what could possible happen. Measure 
> it and see what's happening instead.

Doing that without first establishing a working hypothesis is sunday afternoon science at best.


More information about the KDevelop mailing list