fixed by using an updated libbacktrace
Thu, May 17
Wed, May 16
Tue, May 8
Let's try to fix the bug for real, instead of implementing half-baked workarounds that only work for the default configurations.
Maybe instead use the HighlightText QPalette color? Hardcoding red may work for the two styles you present, but I could just set the view background to red and the text becomes unusable.
Mon, May 7
so what's your plan with this now? Do you actually want to move this forward? Then we need to find a good solution that works everywhere. The numbers aren't that useful on their own, as there the current implementation which is trivial and has no external dependencies is apparently still the best by a margin...
@bshah ping? will you push this?
Fri, May 4
It compiles, how do I test it? Can you please also add a README to the root of this project that explains what this is, does and how to use it?
OK, cool! That clearly shows that this patch _is_ valuable: Before we have ~6% CPU cycle cost, now it's down to 1.5% (inclusively). This is a significant reduction, so I'm all for it.
perf record -g produces unusable data files, since it relies on the frame pointer which is usually not available. Use perf record --call-graph dwarf instead. https://phabricator.kde.org/file/data/w4qogv4brtxlc5p5bnwr/PHID-FILE-q62giymcptudpl5m6bt3/kwrite_perf_after_25_dwarf_caller.png shows ~1.5% in notifyAboutRangeChange (inclusively). Is that before or after your patch here?
Actually, no. Ignore what I said. The pictures you are showing are pretty meaningless. Did you run perf with --call-graph dwarf? Better look at the flamegraph and search for the function you are interested in (Kate::TextBuffer::notifyAboutRangeChange) or use the Caller/Callee view to get an aggregated view of your change.
But the hotspot screenshot clearly shows that you are spending time on optimizing things that are barely noticeable. You have optimized a function that consumes 0.3% of the CPU cycles. It now consumes only ~0.15%, at the cost of slightly higher memory consumption.
Oh and again: please start using perf/hotspot instead of callgrind. Really, the performance numbers you get from callgrind are just *instructions*! It doesn't mean "65% of CPU". It means 65% of the instructions.
lgtm in general, but codewise can be improved
Thu, May 3
Wed, May 2
Tue, May 1
regarding the accessibility interface, I agree that it's out of the scope of this patch. I'd say let's keep it like that for now...
Fri, Apr 27
Tue, Apr 24
Mon, Apr 23
@brauch did you notice any issues? if not, can you accept this then I'll push it.
Apr 22 2018
To query what include files you got, the easiest really is to define the KDEV_CLANG_DISPLAY_ARGS=1 env var. Then you'll see the command line we use for libclang, which includes the include paths. Defines could be queried by setting KDEV_CLANG_DISPLAY_DEFINES=1.
Apr 19 2018
It broke my system... It's looking for all classes in my projects into std::, failing and complaining about it. :'(
Very good. Now I'd like to get some feedback from @apol to see how this works with his android toolchain. I'll also test this later with an arm toolchain and see if it works as expected.
Apr 18 2018
Everyone, please test https://phabricator.kde.org/D12331
Done, Rene - feel free to respin with the issue fixed.
Let's revert and then we can fix it later. This patch is imo less important than a working generic manager. I'll apply the revert now.
ok let's see
Apr 17 2018
I'd appreciate if others could give this a spin and report back whether it is improving things or not.