- User Since
- Apr 16 2015, 7:53 PM (166 w, 2 d)
Thu, Jun 21
I also believe that this is the wrong way for fixing this.
Thu, Jun 14
thanks for fixing the tests! much appreciated
Wed, Jun 13
no clue, I wouldn't be surprised by bugs/regressions in Qt - I've seen a lot of breakage in item/view code recently
this is binary compatible from what I can see
Tue, Jun 12
lgtm too - thanks Heinz
Tue, May 29
ouch, thanks a lot for the investigation. This is similar to the QStringBuilder crashes one can get... Can you simplify the line based on my suggestion? then it's a clear +2 from me, please also include the analysis and valgrind output in your commit message.
May 17 2018
fixed by using an updated libbacktrace
May 16 2018
May 8 2018
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.
May 7 2018
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?
May 4 2018
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
May 3 2018
May 2 2018
May 1 2018
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...
Apr 27 2018
Apr 24 2018
Apr 23 2018
@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
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.