SlickEdit Product Discussion > SlickEdit®

FindInFiles: Performance

(1/4) > >>

jporkkahtc:
FiF seems a bit slow - not sure if it is slower than it used to be though.

Seems like this has something to do with Slick language support, though I've not tried hard to confirm this.
For example, when I did a FiF<WorkSpace>/*, at some point Slick complained about:


--- Code: ---DTD 'http:\\schemas.microsoft.com\developer\msbuild\2003' for file 'C:\src\plugins2blahblah.csproj' not found.
This processing is needed for better color coding and auto completions but can cause delays.

--- End code ---
So, I know that Slickedit is doing some processing on each file it searches.


Is there a way to dumb-down the searching?

Last week I was doing a search of Search&&Replaces. I started by using a Slickedit macro with several instances of:

--- Code: ---_mfreplace2(search_string, replace_string,"LI*",'+t C:\src\plugins\blah\blah',"*.md","<Default Excludes>");

--- End code ---
And found it was running pretty slowly.
I rewrote the macro in Python - doing the same regex F&R operations, and it was dramatically faster.

Clark:
The DTD message sounds like SlickEdit is fetching a DTD for an XML file. That could make things crazy slow. I wouldn't think a multi-file find would cause that to happen. However, a mult-file replace could definitely cause that to happen. If you're getting this with a multi-file find, please provide me with steps to reproduce this.  We plan to add support for disabling the fetching of DTD's in XML files.

As for the _mfreplace2 call I would need a test case to look into. v26 usually does the multi-file find threaded but the replaces are all done on the main thread which slow things down a little.

jporkkahtc:
OK, so I've done some testing.
With a clean configuration doing a Search & replace over 447 files takes 18 seconds.
With my configuration it takes 236 seconds.

With a simple Python script it takes 4 seconds.

I will upload my sample data, macros and python script to Support - under "JPorkkaPerformance"

Clark:
I would like to figure out why your configuration is much slower.

Can you post your user.cfg.xml?

In my testing, most of the time is being spent saving the file.
Here's where the save time is spent:

   * Backup history is very expensive. If you turn that off, this gets about twice as fast.
   * The "save" command displays a message on the message line. This seems to eat a lot more time than you would think.
   * Mult-file undo takes a small amount of extra time. This means that SlickEdit has to a make copy of the original file so you can undo the entire multi-file replace operation. I don't think it's worth it to turn off because it wouldn't speed things up much.

We could add an option to the function you are using to disable backup history for the replace. For a typical user, I wouldn't recommend this. As for the save message, I'll have to look into this further to see what is the best way to improve this.

Clark:
Do you have these *.md files in a project which is currently open? If so, that adds a lot of time due to your files needing to be retagged. For me, this makes things about 3 times slower. Not sure if this explains why you're getting 236 seconds. It might. My machine is MUCH faster than yours.

Try closing your workspace and testing the multi-file replace speed to see how much faster this is.

Navigation

[0] Message Index

[#] Next page