SlickEdit Community
Archived Beta Discussions => SlickEdit 201x Beta Discussions => SlickEdit 2016 v21 Beta Discussion => Topic started by: b on August 30, 2016, 05:56:11 PM
-
In a large source base (e.g., linux kernel source project, u-boot source project in same workspace), I can start a workspace wide search (e.g., 'gpio'). In the same file where there are multiple matches, if minifind is dismissed, using a hotkey to "Next Occurrence" is snappy. With minifind present and then using the hotkey for "Next Occurrence" it is notably laggy just to find the next match in the same file. Dismiss minifind and then the hotkey of the next match is snappy again.
I've even seen some cases that after it jumps to the next file with matches with minfind present that it will get "stuck" on a find and never advance to the next occurrence (pauses like its searching and then stay where it is)
Ubuntu 14.04.4 LTS (x86_64)
-
If you change the search range for the same file from <Workspace> to <Current Buffer> do you experience same lag? I haven't seen anything like that in testing. You can experience a delay if you hit the end of the file and it has to start searching through all the workspace files for the next match. If you can get it to happen again, could you record Slick-C profiling (Macro > Slick-C Profiler > Begin Profiler/Finish Profiler) for a couple of the laggy instances. You should be able to Save the profile data, zip it up and post it here, I'll take a look and see what I can do here.
-
If you change the search range for the same file from <Workspace> to <Current Buffer> do you experience same lag? I haven't seen anything like that in testing.
Yes. I'm working on the profiling now. Here's something is that appears to be weird. Given the following code snippet:
#include <asm/gpio.h>
#ifndef name_to_gpio
#define name_to_gpio(name) simple_strtoul(name, NULL, 10)
#endif
enum gpio_cmd {
GPIO_INPUT,
GPIO_SET,
GPIO_CLEAR,
GPIO_TOGGLE,
};
If I place the cursor on the first 'gpio' and then find next occurrence, I can advance (with lag), but it will then again get "stuck" on the 'name_to_gpio' occurrence. It is as if the leading underscore is throwing it. By "stuck" it doesn't say there is an error, it just searches and keeps at this location and never advance to the next.
Attached is profile on just trying to get to the next occurrence.
Moreover, what is odd, is that I can occasionally reproduce this with minfind present where my hotkey of "Find Next Occurrence" will always get stuck on the next occurrence (regardless which one I start on). I also noted that trying it from Search | Next Occurrence also behaved identically as my hotkey. But after dismissing minfind, then the hotkey advances just fine.
You can experience a delay if you hit the end of the file and it has to start searching through all the workspace files for the next match. If you can get it to happen again, could you record Slick-C profiling (Macro > Slick-C Profiler > Begin Profiler/Finish Profiler) for a couple of the laggy instances. You should be able to Save the profile data, zip it up and post it here, I'll take a look and see what I can do here.
Attached are profiles of the find next with the minifind dismissed as well as with minifind present.
FWIW, I run in VIM emulation.
-
Thanks for all the info. I have been able to reproduce issues specifically with Vim emulation, I am working on fixes for next update.
-
awesome!