Author Topic: SlickEdit 20.0.0.12 freezes often when search window has much data  (Read 5053 times)

rowbearto

  • Senior Community Member
  • Posts: 1974
  • Hero Points: 122
Hi:

SE is freezing up on me often when the search output window has lots of data in it, and I do unrelated operations (not search) while this large amount of data is in the search window. The freezes occur very often when I do many different unrelated things like look at another editor window, or try to do anything else in SE. This even happens with default, blank configuration.

How to reproduce:

0) This was done in windows SE, didn't try in linux but probably same issue.
1) Start SE with a blank configuration, I did: "vs -sc d:/robb/temp/vsblank"
2) Build->Show build to activate the Build window/process buffer (will be used later after the search)
3) Open the very large file (almost 1GB) that I uploaded to support.slickedit.com, the file name is: "DSP_2-bCAM2-SoC2_Traces_18_12_2015_11_52_44.log" (after unzip).
4) Ctrl-F, click "list all occurrences", search for " 0614" (space+614), click Find
5) Wait a VERY long time while SE searches, SE freezes during this time. This freeze is not the main issue that this post is about, but it is still annoying. Eventually the search results window has the data in it.
6) Now switch back to the "Build" tab, or build window, process buffer. At the DOS prompt just click <ENTER>. Now SE freezes for a VERY LONG time. I see no reason for why SE should be freezing here. In fact whenever I try many different things in SE (pressing ENTER was an easy example I could relate), SE kept freezing on me, delaying me from my work of debugging my work.

I know that I can use sgrep as a workaround, and I will, but it requires me to change ingrained habits. So I would very much like to have this problem fixed in case I revert to old habits (Ctrl+F) while not being careful. The disadvantage of using sgrep is that there is only 1 Build window, while with the search results I can have many different search result tabs/windows in parallel. So I would still want to use Ctrl-F for my default searches on smaller files, but have to remember when dealing with large files to switch to sgrep, which I may not always remember to do, and then I would be delayed with more SE freezing.

Thanks!
Rob

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5984
  • Hero Points: 467
Re: SlickEdit 20.0.0.12 freezes often when search window has much data
« Reply #1 on: December 20, 2015, 01:55:20 am »
I'm pretty sure List all occurrences is a foreground operation. The display gets updated but it's still a foreground operation.

If you close the file and do a multi-file search through the one file, you won't have to wait for it to finish (like sgrep). If you don't close the file first this won't be a background search.

We might be able to add an option to list all occurrences to do a multi file search of the file on disk if the file is larger than some size and not modified (with no need to close file first to perform a background operation).

rowbearto

  • Senior Community Member
  • Posts: 1974
  • Hero Points: 122
Re: SlickEdit 20.0.0.12 freezes often when search window has much data
« Reply #2 on: December 20, 2015, 02:40:50 am »
Thanks for the reply Clark.

But after the foreground search is done, SE should not freeze when I do other things, such as press <ENTER> in the Build window, but SE is freezing. This is not good behavior.

I know I can use sgrep, but there is only 1 process tab/buffer. Using Ctrl-F I can output the search results to multiple search output windows, so I usually prefer the search windows. Any chance to add multiple build/process buffer windows for running sgrep in? Then I would switch to sgrep all the time. But to keep multiple search windows, I need to use Ctrl-F, but then remember to switch to sgrep when searching a large file, I may forget sometimes to use sgrep and then SE will become unusable, instead of just freezing during the search (which is annoying but OK), SE freezes for any additional operation afterwards, even if it has nothing to do with search.

I may also forget to close the file, but even if I did, after all the search results are in the search output window, will SE still freeze if I then open the file, and then try other things like pressing <ENTER> in the build window?

So I think there is an issue in SE that after search operation is completely finished, when moving on to other work, SE should not freeze all the time. As I show one example, just pressing <ENTER> in the build window after the search is completely done, SE is freezing. It prevents any further work in SE.

rowbearto

  • Senior Community Member
  • Posts: 1974
  • Hero Points: 122
Re: SlickEdit 20.0.0.12 freezes often when search window has much data
« Reply #3 on: December 20, 2015, 03:05:48 am »
I tried closing the file then doing find in files search. This was better. Then even after I opened the file, went to build window and pressed <ENTER>, there was no freeze.

But still if I happened to do the foreground search (lets say due to habit) and let it finish, why does SE freeze afterwards when I go into the build window and press <ENTER>, or if I do anything else? SE should not freeze when moving on to other, not search related, work.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5984
  • Hero Points: 467
Re: SlickEdit 20.0.0.12 freezes often when search window has much data
« Reply #4 on: December 20, 2015, 03:15:53 am »
Not sure. We will look into this.

I've always wanted multiple process buffers! We still have a pretty sizable list todo before it will make it to the top of the list.

There needs to be an option for using sgrep for multi-file searches since it's much faster and will handle most options (can't handle Match colors, may not be able to match the editors encodings exactly but it should be close enough).

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5984
  • Hero Points: 467
Re: SlickEdit 20.0.0.12 freezes often when search window has much data
« Reply #5 on: December 20, 2015, 03:46:39 am »
Problem appears to be the markup scroll bar. It's converting 260k of offsets to line numbers. This particular test case is perfect to mess up the optimizations we have.
« Last Edit: December 20, 2015, 11:05:26 am by Clark »

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5984
  • Hero Points: 467
Re: SlickEdit 20.0.0.12 freezes often when search window has much data
« Reply #6 on: December 20, 2015, 11:06:54 am »
Added some tweaks to avoid this performance issue. No point in added 260k of scrollbar markup. Not enough pixels on the screen to see it any way. Put in a default limit of 2000.

rowbearto

  • Senior Community Member
  • Posts: 1974
  • Hero Points: 122
Re: SlickEdit 20.0.0.12 freezes often when search window has much data
« Reply #7 on: December 20, 2015, 05:10:13 pm »
Thank you very much Clark! You are a hero!

Could this tweak be deployed via hotfix or new version of SE is required?

For the future, it would be great if you could add multiple process buffers and/or get rid of workaround to close the file first to do it in the background.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5984
  • Hero Points: 467
Re: SlickEdit 20.0.0.12 freezes often when search window has much data
« Reply #8 on: December 20, 2015, 05:15:50 pm »
The plan is to build new installers instead of hot fix. Hopefully this week.

I'll see if we can at least make multifile searching through a large unmodified buffer search in the background.

rowbearto

  • Senior Community Member
  • Posts: 1974
  • Hero Points: 122
Re: SlickEdit 20.0.0.12 freezes often when search window has much data
« Reply #9 on: December 20, 2015, 05:27:14 pm »
Thanks!

I notice you said "unmodified buffer". Sometimes I type notes into the large log file, I guess in that case we have a "modified" buffer. But if I save these notes into the file then would SE treat it as "unmodified" again? I usually do not like to save the notes in case I want to run a different tool which post-processes this data. Just want to understand how it will work.

Thanks,
Rob

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5984
  • Hero Points: 467
Re: SlickEdit 20.0.0.12 freezes often when search window has much data
« Reply #10 on: December 20, 2015, 05:58:01 pm »
Yes, it just needs to be unmodified. Otherwise the results are more likely to be wrong.

rowbearto

  • Senior Community Member
  • Posts: 1974
  • Hero Points: 122
Re: SlickEdit 20.0.0.12 freezes often when search window has much data
« Reply #11 on: December 20, 2015, 05:59:36 pm »
Thank you very much Clark!

Very much looking forward to these excellent tweaks in the next version!

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5984
  • Hero Points: 467
Re: SlickEdit 20.0.0.12 freezes often when search window has much data
« Reply #12 on: December 22, 2015, 02:43:14 am »
20.0.1.3 is available for download.

rowbearto

  • Senior Community Member
  • Posts: 1974
  • Hero Points: 122
Re: SlickEdit 20.0.0.12 freezes often when search window has much data
« Reply #13 on: December 22, 2015, 03:20:39 am »
Thanks! Just installed it!

I see the freezes when doing unrelated activities after the search are gone now. Thanks!

But search still seems to be in the foreground - you probably did not have enough time to use the "Find in Files" for background search yet. But, I'll take it! This is much better than it was before! Now I can continue working!

rowbearto

  • Senior Community Member
  • Posts: 1974
  • Hero Points: 122
Re: SlickEdit 20.0.0.12 freezes often when search window has much data
« Reply #14 on: December 22, 2015, 03:23:20 am »
Even though search is still in foreground, it seems to freeze for much less time during the search than before, maybe because all the scroll bar markup is gone. The wait in the foreground for the search is not so bad. Still not as good as in the background, but also much better than before now that the scroll bar markup is gone. Great work!