mail at milianw.de
Tue Apr 10 18:14:38 UTC 2018
On Dienstag, 10. April 2018 09:38:17 CEST René J.V. Bertin wrote:
> 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
mail at milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the KDevelop-devel