topcontexts

[Milian Wolff]

On Dienstag, 10. April 2018 09:38:17 CEST René J.V. Bertin wrote:
> Hi,
> 
> I saw a comment in the topcontexts implementation file how the mmap'ping
> feature could be problematic on some platforms because there are really 
> lots of maps made. Has this feature ever been benchmarked (in recent times
> and "in situ")?
> 
> I #undef'ed USE_MMAP to see what difference it made and on Mac at least I
> don't think I'd be able to tell the with and without versions apart in a
> double blind test, performance wise (with the topcontexts directory in
> place, evidently). The memory footprint might be smaller but that shouldn't
> be by an amount larger than `du /path/to/topcontexts`, should it?

There is once again a lot of confusion flying around in this thread...

So, to clear some stuff up:

- the actual loading code of topducontexts wasn't ever a big performance issue 
when I profiled KDevelop, rather what was slow was actually using the loaded 
data afterwards (afaik it's been a long time)
- the memory gain indeed should only be in the order of what you get by `du`
- when you look at a cache created by kdev-clang, it will (hopefully) be 
somewhat smaller than what we used to have with oldcpp, which had to seriliaze 
more information there. Similarly, a cache for a big PHP or Python project may 
also be larger
- to me, the memory savings are quite nice to have, but not crucial

Now, more importantly:

If you would actually finally start using a profiler, we could see whether 
this code is actually a performance issue or not. As I said, it never popped 
up when I profiled KDevelop. So I once again think you are prematurely 
optimizing instead of spending the time to figure out how to use a sampling 
profiler as well as a tracing I/O or off-CPU profiler and understanding its 
output. I believe it would be beneficial to everyone, we wouldn't waste time 
on arguing for or against mystical performance problems in code that noone 
really cares about. You would finally start to find actual performance 
problems and can start fixing those...

I'm seriously fed up by this. It's a repeat pattern. You find something and 
claim it's slow or whatever and then waste everyones time by dragging us into 
these endless discussions. Meh, maybe I should once again go into ignore mode 
for these threads



-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20180410/64df6560/attachment.sig>