Author Topic: SLick 13.0.1 unresponsive when it gets focus  (Read 16747 times)

skywise

  • Senior Community Member
  • Posts: 331
  • Hero Points: 10
Re: SLick 13.0.1 unresponsive when it gets focus
« Reply #15 on: August 07, 2008, 05:57:34 pm »
FYI, I've seen this issue on my corporate office version of XP as well which I edit on a mapped network drive (linux share), but NOT on my laptop running XP Pro (which has a mapped network drive but I don't often edit with).  Tag files et/all are kept on my local hard drive on both.

(REALLY kept on my local hard drive... I used to have my tag files/configurations/project files stored in "My Documents" folder on the corporate PC but later discovered that our IT guy had quietly added the "feature" to store all My Documents folders on a network drive for easy back up and had redirected them one night.  So I went for about 2 months with sluggish performance on several tools I use thinking my computer was just getting "old".  Now they're kept on a special folder on my C drive...)

Lee

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1299
  • Hero Points: 130
Re: SLick 13.0.1 unresponsive when it gets focus
« Reply #16 on: August 07, 2008, 09:00:59 pm »
Those are tests are useful, it doesn't appear that available memory is an issue.  tag_read_db can be another I/O intensive user, there are a number of tests to check that the tag file is valid, writable, as well as flush any uncommitted changes to file.  You could try running Process Monitor (or the older File Monitor) and log SlickEdit's file activity (point your browser to sysinternals.com and it will direct you to the right download spot).  Even that may not give a clear picture of what exactly is going on and may even change the results just by observing it (aka a heisenbug).  And don't be alarmed, SlickEdit does *alot* of I/O under the covers, just look for any large gaps in the timestamp for the operations.
« Last Edit: August 07, 2008, 09:06:22 pm by Lee »

jporkka

  • Senior Community Member
  • Posts: 136
  • Hero Points: 6
Re: SLick 13.0.1 unresponsive when it gets focus
« Reply #17 on: August 08, 2008, 12:51:37 am »
OK, seems to be the VTG file.

There are several operations around the VTG: read, close, create, and FlushBuffersFile (maybe a proc mon typo meaning FlushFileBuffers?).
There is a 5 second pause after FlushFileBuffers before the Close operation, then it reopens and starts reading.

Lee

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1299
  • Hero Points: 130
Re: SLick 13.0.1 unresponsive when it gets focus
« Reply #18 on: August 08, 2008, 03:57:10 pm »
This was the workspace tag file, correct?  The workspace tag file can be updated in a background process.  There are a number of checks to make sure the file is up-to-date and that the read-write permissions are correct for sharing among process, so the file handle can get closed and re-opened quite a bit with different permissions, and the flush is called for sanity.  The only thing I'm not sure of is if there were any previous writes that actually required the flush here.

We'll have to review this, so unfortunately I don't have any answers for you at this time.

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: SLick 13.0.1 unresponsive when it gets focus
« Reply #19 on: August 08, 2008, 05:23:35 pm »
Just some trivia:  FlushFileBuffers isn't needed for coherency for multi-process access on Windows NT/2000/XP/2K3/Vista/2K8.  The OS disk cache guarantees coherency without any need for explicit flushes, even when accessed by multiple processes concurrently over the network.  Third party networking solutions were known to have some issues with networked file IO on Win9x where hardware access was not virtualized, though.  FlushFileBuffers does make sure the data hits the physical disk, which can be useful for other reasons of course (and for Win9x in general).

(Edit: added Win2000 to the list; its accidental omission could have been ambiguous).
« Last Edit: August 08, 2008, 07:02:04 pm by chrisant »

jporkka

  • Senior Community Member
  • Posts: 136
  • Hero Points: 6
Re: SLick 13.0.1 unresponsive when it gets focus
« Reply #20 on: August 08, 2008, 06:30:43 pm »
Very good point.
Given that it is just for tags, I'd be OK if the tag file has to get rebuilt when I get a dirty shutdown (power loss, BSOD).
FFB may not even work (on dirty shutdown) as typical IDE drives lie to the OS and don't flush their cache anyways in some cases.

I don't think we need to worry about what Win9x did anymore, do we?

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: SLick 13.0.1 unresponsive when it gets focus
« Reply #21 on: August 08, 2008, 07:33:45 pm »
I don't think we need to worry about what Win9x did anymore, do we?

Right, SlickEdit doesn't needs to worry about Win9x (the System Requirements page says "Microsoft® Windows® Vista™, XP, 2000" which could probably be amended to list 2K3 and 2K8).  I just didn't want to by omission mislead a reader who might still be writing software that supports Win9x, since this is a forum that I assume is read by a wide array of developers.  ;)

jporkka

  • Senior Community Member
  • Posts: 136
  • Hero Points: 6
Re: SLick 13.0.1 unresponsive when it gets focus
« Reply #22 on: October 20, 2008, 05:11:33 pm »
I hope this gets fixed in future versions of slick - any word on that?

I have my own fix for it that does improve performance noticeably.

Try this at your own risk, but I've been using it for a few days now with no ill effects and I like the perf improvement.

In C:\Program Files (x86)\SlickEdit 2008\win\TAGSDB.dll (version 13.0.2.0)
At Offset 0x5a57ae4 change bytes "FF 15" to "eb 1b"
This skips the flushfilebuffers call.

(Be sure to keep a copy of the original file around).

sdonepudi

  • Community Member
  • Posts: 23
  • Hero Points: 0
Re: SLick 13.0.1 unresponsive when it gets focus
« Reply #23 on: November 04, 2008, 04:10:37 pm »
I am having the same issue and it is very frustating. I could not find the address  0x5a57ae4 you have mentioned. Is this address correct in tagsdb.dll.

Thanks,
sdonepudi

jporkka

  • Senior Community Member
  • Posts: 136
  • Hero Points: 6
Re: SLick 13.0.1 unresponsive when it gets focus
« Reply #24 on: November 12, 2008, 07:12:27 pm »
Oops ... that was I think the inprocess address.
The offset in the file is actually 0x76EE4

C:\Program Files (x86)\SlickEdit 2008\win> comp tagsdb.dll tagsdb.dll.ORIG

Comparing tagsdb.dll and tagsdb.dll.ORIG...
Compare error at OFFSET 76EE4
file1 = EB
file2 = FF
Compare error at OFFSET 76EE5
file1 = 1B
file2 = 15

dunkers

  • Senior Community Member
  • Posts: 689
  • Hero Points: 28
Re: SLick 13.0.1 unresponsive when it gets focus
« Reply #25 on: November 21, 2008, 12:27:46 am »
WoW! My SE has been a bit slow generally, sometimes not keeping up with what I'm doing. Often, I'll click in a different edit window and then select a tab to display in it, and the tab goes to the original window because SE is taking a second or two to make the switch. I just made your change and SE is flying again!

Thanks for persevering with this, jporkka. Hopefully SE will incorporate this in its next upgrade, if not sooner.

sdonepudi

  • Community Member
  • Posts: 23
  • Hero Points: 0
Re: SLick 13.0.1 unresponsive when it gets focus
« Reply #26 on: November 21, 2008, 04:39:19 pm »
I have made the changes suggested by  jporkka and I have observed Slickedit Performance improved.

sdayts

  • Community Member
  • Posts: 42
  • Hero Points: 5
Re: SLick 13.0.1 unresponsive when it gets focus
« Reply #27 on: March 20, 2009, 01:40:40 pm »
Thank you jporkka.  I have made the suggested changes to tagsdb.dll and these annoying freezes have stopped happening.  Have been running with this change for a couple of days without any negative side effects so far.

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: SLick 13.0.1 unresponsive when it gets focus
« Reply #28 on: March 20, 2009, 04:21:53 pm »
The SE team has removed the FlushFileBuffers call from the upcoming SE 2009 here.