Cutter: Adding multithreading for the interface (like as quick filter, highlight selected register )

Created on 10 Nov 2018  路  8Comments  路  Source: rizinorg/cutter

It makes a lot of people happy.

Enhancement Performance

Most helpful comment

A big part of the issue I've seen, with the quick filters, is that typing into them is terribly slow. However, this is typically just for the first few chars, since there are so many matches. For example, if I want to find foo in the strings for a binary, typing f will freeze the app for a few minutes, then o will freeze the app for a few seconds, then the final o will be quick.

So, for this situation anyway, it seems like a thread would work quite well IF the task can be cancelled or changed as soon as the input changes. That way the flow is like this:

  1. Type f and trigger a thread to do the filter; the UI stays responsive
  2. Type o and cancel/change the previous search thread; the UI stays responsive
  3. Type o and cancel/change the previous search thread; the UI stays responsive

As soon as any search thread finishes, the results are populated. In my situation, which I take to be the most common, I'm never going to want to search for a single character in the strings list.

The only other way I see around this, aside from just making things faster in the first place, is to not search when typing. If there's a search button and/or if Cutter searches on enter press, we can skip this whole searching all strings for the first character as you type problem.

As a side note, for anyone finding this ticket out of frustration, if you type your string elsewhere, then copy/paste it into Cutter, the results will show quite quickly. This is because it's only doing one search, for your exact string, rather than a search for every char you type.

All 8 comments

I think we need a better plan here. Someone have examples or ideas how can we achieve this?

There is already AsyncTaskManager in Cutter, which can do this. But for most things, it's not trivial to implement. For example the quick filter just uses QSortFilterProxyModel and this is simply not designed to work asynchronously.

Users want speed. Multi-threading usually hides underlying performance issues rather than solving them like we discussed on radare2.

A big part of the issue I've seen, with the quick filters, is that typing into them is terribly slow. However, this is typically just for the first few chars, since there are so many matches. For example, if I want to find foo in the strings for a binary, typing f will freeze the app for a few minutes, then o will freeze the app for a few seconds, then the final o will be quick.

So, for this situation anyway, it seems like a thread would work quite well IF the task can be cancelled or changed as soon as the input changes. That way the flow is like this:

  1. Type f and trigger a thread to do the filter; the UI stays responsive
  2. Type o and cancel/change the previous search thread; the UI stays responsive
  3. Type o and cancel/change the previous search thread; the UI stays responsive

As soon as any search thread finishes, the results are populated. In my situation, which I take to be the most common, I'm never going to want to search for a single character in the strings list.

The only other way I see around this, aside from just making things faster in the first place, is to not search when typing. If there's a search button and/or if Cutter searches on enter press, we can skip this whole searching all strings for the first character as you type problem.

As a side note, for anyone finding this ticket out of frustration, if you type your string elsewhere, then copy/paste it into Cutter, the results will show quite quickly. This is because it's only doing one search, for your exact string, rather than a search for every char you type.

As a side note, for anyone finding this ticket out of frustration, if you type your string elsewhere, then copy/paste it into Cutter, the results will show quite quickly. This is because it's only doing one search, for your exact string, rather than a search for every char you type.

Maybe a temporary work-around is a timer that delays the actual search for some milliseconds after a char is typed? When the last char is typed, the string will be searched only once since - if the user's typing speed matches the delay of the timer of course.

Maybe a temporary work-around is a timer that delays the actual search for some milliseconds after a char is typed? When the last char is typed, the string will be searched only once since - if the user's typing speed matches the delay of the timer of course.

A variation of this without timer is using QLineEdit::editingFinished() signal which gets emitted after pressing enter or loosing focus instead of each character as it is for textChanged() . There is also textEdited() not sure how often that gets triggered and if the only difference from textChanged is handling of text changes done by code.

Maybe a temporary work-around is a timer that delays the actual search for some milliseconds after a char is typed? When the last char is typed, the string will be searched only once since - if the user's typing speed matches the delay of the timer of course.

A variation of this without timer is using QLineEdit::editingFinished() signal which gets emitted after pressing enter or loosing focus instead of each character as it is for textChanged() . There is also textEdited() not sure how often that gets triggered and if the only difference from textChanged is handling of text changes done by code.

That's even simpler but requires the user to hit enter instead of searching "on the fly" as the user is typing. Not that it's a big deal of course, just saying.

Was this page helpful?
0 / 5 - 0 ratings