Hi,
Since I updated from the previous to the latest TM version, any time I switch from another application to a TM window TM is unresponsive (pizza wheel) for approximately 3 seconds (time appears to depend on how many projects are open).
Even if I have TM front, click any other App's window and immediately back to TM that delay is observed.
Gerd
How many files are in your project? If you have hundreds / thousands, that would account for it. Each time TM receives focus, it rescans the directories associated with the project to find if it needs to update the project file listing. But that isn't anything new with the latest build.
I removed several references to directories from my project that contained files that I would never be editing in TM anyway. That "fixed" the issue for me.
On Dec 20, 2005, at 9:33 AM, Gerd Knops wrote:
Hi,
Since I updated from the previous to the latest TM version, any time I switch from another application to a TM window TM is unresponsive (pizza wheel) for approximately 3 seconds (time appears to depend on how many projects are open).
Even if I have TM front, click any other App's window and immediately back to TM that delay is observed.
Gerd
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
an option to turn this off would be extremely help for those of us with projects on network shares. Textmates ability to open a folder of files is really useful when the files are local, but unusable when on a share. I'd happily trade the project folder recognising updated files, for it actually being usable.
Could it just not scan any files/folders which are not local, or alternatively perform the scan asynchronously?
jebw
On 20 Dec 2005, at 17:53, Brad Choate wrote:
How many files are in your project? If you have hundreds / thousands, that would account for it. Each time TM receives focus, it rescans the directories associated with the project to find if it needs to update the project file listing. But that isn't anything new with the latest build.
I removed several references to directories from my project that contained files that I would never be editing in TM anyway. That "fixed" the issue for me.
On Dec 20, 2005, at 9:33 AM, Gerd Knops wrote:
Hi,
Since I updated from the previous to the latest TM version, any time I switch from another application to a TM window TM is unresponsive (pizza wheel) for approximately 3 seconds (time appears to depend on how many projects are open).
Even if I have TM front, click any other App's window and immediately back to TM that delay is observed.
Gerd
_ For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
--- Jeremy Wilkins Ibex Internet Ltd
Parkside Business Park Parkside Rd. Kendal Cumbria LA9 7EN
Tel: 0845 226 8342 Fax: 08718 729374
On 20/12/2005, at 19:08, Jeremy Wilkins wrote:
an option to turn this off would be extremely help for those of us with projects on network shares [...]
http://lists.macromates.com/pipermail/textmate/2005-August/005139.html
On Tue, Dec 20, at 12:17 PM, Allan Odgaard wrote:
On 20/12/2005, at 19:08, Jeremy Wilkins wrote:
an option to turn this off would be extremely help for those of us with projects on network shares [...]
http://lists.macromates.com/pipermail/textmate/2005-August/005139.html
It *IS* a static project. About 100-200 files located on NFS. And I am quite positive this is new behavior since the last release.
Alan, are previous dailies still available? I can only see the last one. I gladly do back a version to verify that this is newly introduced behavior (though it is SO annoying that I know I would have noticed, as I work with that particular project every day).
Gerd
On 20/12/2005, at 19:44, Gerd Knops wrote:
It *IS* a static project. About 100-200 files located on NFS. And I am quite positive this is new behavior since the last release.
Alan, are previous dailies still available?
Yes, they're linked to from the app-cast feed: feed:// appcast.textmate.org
I can only see the last one. I gladly do back a version to verify that this is newly introduced behavior [...]
I really have no idea what should have changed in this department. You might help diagnose the problem by running Shark on TextMate while re-activating it.
On Tue, Dec 20, at 1:10 PM, Allan Odgaard wrote:
On 20/12/2005, at 19:44, Gerd Knops wrote:
It *IS* a static project. About 100-200 files located on NFS. And I am quite positive this is new behavior since the last release.
Alan, are previous dailies still available?
Yes, they're linked to from the app-cast feed: feed:// appcast.textmate.org
OK, went back all the way to 680, they all show the problem. Guess somehow networking performance here went to hell.
I can only see the last one. I gladly do back a version to verify that this is newly introduced behavior [...]
I really have no idea what should have changed in this department. You might help diagnose the problem by running Shark on TextMate while re-activating it.
Shark indicated almost all of the time was burned up in lstat and in the underlying kernel routines. 'fs_usage -f filesys' confirmed that on activation the TextMate process performs 3432(!!!) lstat calls. For each file in my (static) project it does a lstat for every single path component, eg for the file /a/b/c/d it performs lstat calls for / a, /a/b, /a/b/c and /a/b/c/d. And the root of my project starts 6 levels deep in the file system...
Part of the slowdown appears to stem from the fact that my system started heavy swapping, despite 1.5GB memory. Guess I'll have to check in more detail what is going on.
Gerd
On 20/12/2005, at 21.13, Gerd Knops wrote:
TextMate process performs 3432(!!!) lstat calls. For each file in my (static) project it does a lstat for every single path component, eg for the file /a/b/c/d it performs lstat calls for / a, /a/b, /a/b/c and /a/b/c/d. And the root of my project starts 6 levels deep in the file system...
Perhabs some optimization is possible here, by statting recusively. Of course I don't know how Allan does this, and it might be through higher level calls.
-- Sune.
On 20/12/2005, at 21:13, Gerd Knops wrote:
Shark indicated almost all of the time was burned up in lstat and in the underlying kernel routines. 'fs_usage -f filesys' confirmed that on activation the TextMate process performs 3432(!!!) lstat calls. For each file in my (static) project it does a lstat for every single path component, eg for the file /a/b/c/d it performs lstat calls for /a, /a/b, /a/b/c and /a/b/c/d. And the root of my project starts 6 levels deep in the file system...
I had forgotten that even for a static project, I still call NSFileManager's fileExistsAtPath: on re-activation, to detect if any files has gone AWOL since last use (I'll be sure to also do that lazy/ async. in 1.2).
I can easily swap the code with something more low-level as a quick fix, but I'm too pressed for time to experiment with this myself (benchmarking the alternatives etc.).
-
Allan Odgaard -
Brad Choate -
Gerd Knops -
Jeremy Wilkins -
Sune Foldager