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.