This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115976/

On February 23rd, 2014, 6:57 p.m. UTC, Sven Brauch wrote:

We're starting to have a lot of those algorithms now -- kdevelop has one for quickopen, kate has one for the completion list and now one for quickopen too. Maybe we could determine some shared functionality and put it in KTextEditor for all three places to re-use? We'd just need to discus what functionality that would be.

Apart from that, my experience from kdevelop's quickopen is that arbitrary distance of characters easily yields weird results when applied to longer paths. But maybe that's fixed by your sorting algorithm.

Does kate's quickopen filter all files when you have a project open, or always just open files? In the former case, is the regex approach fast enough?

On February 23rd, 2014, 10:26 p.m. UTC, Kirill Bogdanenko wrote:

> Does kate's quickopen filter all files when you have a project open, or always just open files? In the former case, is the regex approach fast enough?

quickopen filter is applied to all documents that are available, these are:
1. Views
2. Opened documents
3. Project files
(for details see KateQuickOpen::update method in kate/app/katequickopen.cpp)

In the case regex approach is fast enough (but actually can be replaced by wildcard otherwise). At least I hadn't experienced any slowdowns on kate.git project on my laptop (dual-core i7-2640M, 8 GiB RAM). But I haven't done any real benchmarks.

On February 23rd, 2014, 10:48 p.m. UTC, Kirill Bogdanenko wrote:

... but probably it's worth to override filter's filterAcceptsRow() method and get rid of regexp matching.

Algorhithm can be like as follows:

  int lastPos = -1;

  for (int i = pattern.length() - 1; i >= 0; i--) {
      int pos = candidate.lastIndexOf(pattern[i], lastPos);
      if (pos != -1) {
          lastPos = pos;
      } else {
          return false;
      }
  }

Can you advice some benchmarking tool that will help to compare these approaches?

On February 23rd, 2014, 11:39 p.m. UTC, Sven Brauch wrote:

Milian is the resident expert on benchmarks around here, but if you write a unit test (which is always awesome anyways) you can easily use QBENCHMARK to compare the approaches. A simpler method is just putting QTime t; t.start; [do stuff] qDebug() << t.elapsed() around your code.
More serious benchmarking can use valgrind --tool=cachegrind or intel's vtune, but I doubt that's worth it in this case.

Jup, a QBENCHMARK would be greatly appreciated. 

QElapsedTimer based "profiling" is only a good tool to quickly verify hotspots found by other means, such as perf, callgrind or vtune. A QBENCHMARK is still needed in order to systematically improve performance and ensure that no performance regressions creep in.

- Milian

On February 23rd, 2014, 6:44 p.m. UTC, Kirill Bogdanenko wrote:

Review request for Kate, Christoph Cullmann and Dominik Haumann.

By Kirill Bogdanenko.

Updated Feb. 23, 2014, 6:44 p.m.

Bugs: 328569

Repository: kate

Description

Wildcard-like search string for Quick Open

* Search string turns into regexp like:

    foo -> /f.*o.*o.*$/

  (special characters in original pattern are escaped)

* Filtered items are sorted using edit (Levenstein) distance

Diffs

kate/app/CMakeLists.txt (f39bf68)
kate/app/katequickopen.h (175826e)
kate/app/katequickopen.cpp (235f9f1)
kate/app/katequickopenproxymodel.h (PRE-CREATION)
kate/app/katequickopenproxymodel.cpp (PRE-CREATION)

View Diff