KDevelop 5 too slow?

[René J.V. Bertin]

On Monday May 29 2017 10:52:00 Milian Wolff wrote:

Hi,

>> I'm not very familiar reading this kind of call graph, but if you follow the
>> graph down clang_getFileLocation shows up which accounts for almost 24% of
>> the processing time on my system. That could correspond to disk access, no?
>
>No, CPU profilers do not account for disk access. I'm not familiar with 

My bad, I didn't mean to claim that it does any analysis of disk access itself. As far as I understand this sort of thing that would only exclude 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?
IOW, clang_getFileLocation() is doing something that takes 24% of all spent CPU cycles, and given the name of the function that is related to I/O in some way.

>Perf or VTune are just as capable.

But most Linux systems don't come with the required kexts installed, do they?

>Also, to make sure: Did you compile KDev* 
>and everything else you are profiling in RelWithDebInfo mode? If not, then 
>this profile output is completely useless.

I build with "-O3 -g" if that's what you're asking, everything KF5 and Qt5 itself. Specifically, I use Debuntu's approach of building with a custom, non-predefined BUILD_TYPE and then set the desired compiler options in CFLAGS and CXXFLAGS.

>There's N + 1. N for background parsing and one for parsing the active 
>document, if needed.

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.

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"?

>>  if KDevelop is slower running
>> from one than as/from a regular install the 1st explanation one thinks of
>> is "something related to the bundling".
>Before doing such a claim, back it up with hard numbers. Profiling and 

Eh? I didn't claim anything that needs backing up with hard numbers, unless you mean the number of people who actually decide to check if that 1st explanation is the right one? :)

> Can you use a
> different instruments profiler configuration to find wait time in the code?
> That would allow us to get a more accurate image of what's going on. Also,
> make sure to profile the same thing.

There's a whole bunch of preconfigured "Instruments", I'll have to see if I can figure out which would be the appropriate one for wait time.

> I.e. I suggest you clear the duchain
> cache before starting KDevelop with the profiler.

I can't clear the cache while KDevelop is running, can I? That means I'd be measuring KDevelop's start-up too meaning loads more data or less fine-grained sampling. I'm also not convinced that measuring the cost of rebuilding the entire cache is what we're interested in here, that shouldn't be what causes the reported slowness, right?
As to measuring the same thing: I make sure to force the parsing step 2 or 3 times before sampling the operation. I don't expect it makes a difference if I do that 2x or 3x but it'd probably be better indeed to standardise.

R.