Search operation executes on dispatcher thread #59

Open
opened 2015-06-08 02:54:30 -05:00 by dmit25 · 3 comments
dmit25 commented 2015-06-08 02:54:30 -05:00 (Migrated from github.com)

Hi, this project is just brilliant and I've been using it for a couple years for now.
The only one problem is UI freezes when working with huge documents >10Mb and active search running.
The root of the problem is that offsets calculation process is running in the main UI thread, matching big text using regexps takes a lot of time ( e.x. on my machine when 20 Mb file is opened and any type of search active any keypress leads to 2,2 secs delay, matching text with simple regex takes about 2,1 secs).
So the first thought - move matching phase to another thread, additionally add interception code in each iteration so that any running background process could be easily stopped by new one (typing -> search started, typing before search completed -> search process stopped and new one started).

I've worked a bit on this problem and have some implementation in my fork (worked out dispatcher issues + interception implementation), no more freezes during typing + simplified search dependencies, unfortunately I've abandoned some search functionality? but I'm sure that with your help we can implement match whole word without document dependency (so it could run in parallel thread).

If you are interested in this type of functionality I can upload performance reports and send pull request.

Again, thanks for your work.

Hi, this project is just brilliant and I've been using it for a couple years for now. The only one problem is UI freezes when working with huge documents >10Mb and active search running. The root of the problem is that offsets calculation process is running in the main UI thread, matching big text using regexps takes a lot of time ( e.x. on my machine when 20 Mb file is opened and any type of search active any keypress leads to 2,2 secs delay, matching text with simple regex takes about 2,1 secs). So the first thought - move matching phase to another thread, additionally add interception code in each iteration so that any running background process could be easily stopped by new one (typing -> search started, typing before search completed -> search process stopped and new one started). I've worked a bit on this problem and have some implementation in my fork (worked out dispatcher issues + interception implementation), no more freezes during typing + simplified search dependencies, unfortunately I've abandoned some search functionality? but I'm sure that with your help we can implement match whole word without document dependency (so it could run in parallel thread). If you are interested in this type of functionality I can upload performance reports and send pull request. Again, thanks for your work.
siegfriedpammer commented 2020-02-04 07:06:17 -06:00 (Migrated from github.com)

Would you still be interested/able to provide your changes as a pull request?

Would you still be interested/able to provide your changes as a pull request?
dmit25 commented 2020-02-04 09:08:34 -06:00 (Migrated from github.com)

Oh, I no longer work with this library, but I guess it is possible to pick up changes from my fork. I guess it's not urgent :) I'll try to create a proper PR.

Oh, I no longer work with this library, but I guess it is possible to pick up changes from my fork. I guess it's not urgent :) I'll try to create a proper PR.
siegfriedpammer commented 2020-02-04 09:22:33 -06:00 (Migrated from github.com)

Honestly, I did not expect a response... take your time :) Thank you very much!

Honestly, I did not expect a response... take your time :) Thank you very much!
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-icsharpcode/AvalonEdit#59
No description provided.