SE18b2 (win7 x64) seems slow compared to SE17

[jc44]

By and large SE18 seems to work, but it seems really quite slow compared to SE17.  It can stall for a couple of seconds at a time when thinking about variable or syntax expansion.  SE17 suffered from this sort of problem as well but nowhere near as severely.

When deleting buffers from the Brief Alt-B buffer window with Alt-D it takes almost a second to kill a single buffer! (If I multi-select buffers then it still takes about a second so I guess it is the effort involved in updating the window rather than the delete.)  in earlier versions I used to be able to hold down Alt-D and they would die at auto-repeat rates.  And moving the buffers window around is either very jerky or I just get a blue rectangle until I put it down - why?

[jporkkahtc]

I agree ... seems much slower, especially the first time a symbol is referenced.
I've been getting pauses long enough for windows to call VS unresponsive much more often than with 17.

[Dennis]

Could you run Slick-C profiling when you are seeing these delays and then send in the profiling results.

Macro > Slick-C Profiling > Start Slick-C Profiler
Macro > Slick-C Profiling > Save...

If you are seeing delays on specific keyboard commands, like syntax expansion, you can execute "profile key" from the command line to profile a single action.

[jc44]

OK - here you go - this is for adding the following fn to an existing file:
int wombat_fun()
{
}

The longish delays are on typing ( and {.

However the longest delay (~15 secs and it caused the SE window to grey out as unresponsive) was executing the "Finish profiling..." command!  Also the profile window it generated was very slow and clunky when asked to scroll - these days any text application should be able to do that without visible delay.

[Clark]

You may have this problem:

http://community.slickedit.com/index.php/topic,9066.0.html

[jc44]

Possibly - but if I do it isn't persistent - general cursor movement is still good in the main edit window and I note (having looked at it for a bit longer) that even the profiler window behaves as I would hope after a minute or two (whether I play with it or not).

[jc44]

I may have seen your issue - certainly scrolling seemed slower than it should in the main window and it persisted across a restart so here is my vrestore.slk

As another bizarre feature: I copied the file to my desktop and dragged it into SE so I could see what I was sending  - so far so good - some sort of text file.  But vrestore.slk doesn't show up in my (Brief: Alt-b) buffers list - not even when it is my current buffer and so should be the current selection.

[jc44]

I'm going to assert that I have taging issues (though I may have others as well :-)).  I set off a tag file rebuild (foreground, all files, generate refs) on the offchance that something there had become confused and it would help. It is running a lot slower (~15-20 files/sec) than it did in 17.0.3. (which I recon did ~50-100files/sec with the same options).

[Clark]

Do you have many XML files in your workspace?

[jc44]

There are no XML files in the project - just a lot of C and a bit of C++ (total ~24000).
If I had to guess what was going on I'd guess that you were reading the source files in smaller chunks than before.  The sources are mounted over the network and I've observed in the past that it much prefers a few big reads to lots of small (in the past I've managed to get order of magnitude improvements in file compare progs by reading in MB chunks rather than KB).

[Clark]

I tested it yesterday on C++ files and it was slower. We are looking into it.

[Clark]

I was incorrect. V18 is definitely not slower than v17 at tagging local files. I was using a new allocator which was not checked into the V18 source code and it was the problem. I tagged approximately 21615 files with references and it created a 111MB tag file.

Your test case is with remote files. I'll do the same test with remote files.

[jc44]

Thanks - for what its worth my tag file is a bit bigger than yours @ ~292MB

[Clark]

Scratch my last post. There is a tagging performance problem with local files. Someone else made a change that I didn't notice.  I blamed my new unchecked in allocator because I thought it was the only difference between my test cases. Anyway, the performance problem has been fixed!

I'll test remote files too to make sure there is no problem there either.

[jc44]

Indeed - I've just got b4 and we seem to be back to approx. v17 speeds now.

Many thanks