TextMate 2 seems very promising feature wise, but one of my biggest complaints with version 1 was the slow performance of extremely large projects (20k+ files), particularly when using the "Go to file" command. I was very disappointed then to see that the v2 alpha is even slower in this regard, unusably so. When I try to type a file name, one letter appears at a time with up to ten seconds in between, and this is on a quad core i7 with an SSD. Even using the `find` command from the terminal is faster, and it walks the entire directory tree every time.
I understand that this is an alpha, and that performance was one of the things that was left for later tuning. But I'm afraid that more than tuning is needed in this case, although I could be wrong. I would simply ask that the performance of large projects be made more of a priority than it currently is.
Thanks, Connor McKay
On 15/01/2012, at 03.37, Connor McKay wrote:
[…] I understand that this is an alpha, and that performance was one of the things that was left for later tuning. But I'm afraid that more than tuning is needed in this case, although I could be wrong.
The ⌘T filtering uses display names which turns out to be a major performance bottleneck since getting the display name requires accessing the file system several times (and the OS seems to not cache it) — I may drop using display names and/or do my own caching of these (display names allow localized file names, turns ‘:’ into ‘/’, hide extensions, a.s.o.).
I would simply ask that the performance of large projects be made more of a priority than it currently is.
A priority is observed, not manufactured or assigned :)
Ah, I was unaware of the existence of display names. Caching them sounds like a good idea to me, since I assume the display names are used in the file explorer as well.
Thanks Allan!
On Sunday, January 15, 2012 at 8:24 PM, Allan Odgaard wrote:
On 15/01/2012, at 03.37, Connor McKay wrote:
[…] I understand that this is an alpha, and that performance was one of the things that was left for later tuning. But I'm afraid that more than tuning is needed in this case, although I could be wrong.
The ⌘T filtering uses display names which turns out to be a major performance bottleneck since getting the display name requires accessing the file system several times (and the OS seems to not cache it) — I may drop using display names and/or do my own caching of these (display names allow localized file names, turns ‘:’ into ‘/’, hide extensions, a.s.o.).
I would simply ask that the performance of large projects be made more of a priority than it currently is.
A priority is observed, not manufactured or assigned :) _______________________________________________ textmate mailing list textmate@lists.macromates.com (mailto:textmate@lists.macromates.com) http://lists.macromates.com/listinfo/textmate
On 16.01.12 04:24, Allan Odgaard wrote:
The ⌘T filtering uses display names which turns out to be a major performance bottleneck since getting the display name requires accessing the file system several times (and the OS seems to not cache it) — I may drop using display names and/or do my own caching of these (display names allow localized file names, turns ‘:’ into ‘/’, hide extensions, a.s.o.).
If you decide to keep using display names, could that be made configurable? I for one would prefer to see the real file names instead, even if the performance was the same. I know that is not the HIG standard, my preferences do not always follow that. :-)
Christopher
On 20/01/2012, at 15.44, Christopher Creutzig wrote:
If you decide to keep using display names, could that be made configurable?
There presently is a “display all filename extensions” in Preferences → Projects. While presently a no-op, my intent is for this to mostly suppress display names.
That said, display names are also things like making “/” show as “Macintosh HD” (or whatever it is named), so not sure we can do entirely without them.
FYI current test build (r9005) does not use display names for ⌘T.
And a general PSA, lack of regular updates to TM is partly because I recently relocated and is still settling in.
On 21.01.12 04:18, Allan Odgaard wrote:
That said, display names are also things like making “/” show as “Macintosh HD” (or whatever it is named), so not sure we can do entirely without them.
Like I said, I'd actually prefer that. I spend half my time on the command line, where it's called “/”. It's even called “/” when I use ⌘⇧G in a file dialog or Finder window, little as I touch them. I can live with display names, but if I could get rid of them, that would be an improvement. For the whole system.
FYI current test build (r9005) does not use display names for ⌘T.
Thanks, I'll try that out.
BTW, I get a lot of these in my logs:
23.01.12 08:31:55 /Applications/alpha/TextMate.app/Contents/MacOS/TextMate[92977] /home/ccreutzi/Library/Application Support/TextMate/Session/Info.plist~: set flags (was: 00000000): Operation not supported
I assume that's expected for a non-HFS+ home?
Christopher
On 23/01/2012, at 14.37, Christopher Creutzig wrote:
BTW, I get a lot of these in my logs:
23.01.12 08:31:55 /Applications/alpha/TextMate.app/Contents/MacOS/TextMate[92977] /home/ccreutzi/Library/Application Support/TextMate/Session/Info.plist~: set flags (was: 00000000): Operation not supported
I assume that's expected for a non-HFS+ home?
I can’t find a line in TextMate that would produce this output.
But it’s clearly indicative of missing support for some file system operation, so to that extend, it might be expected if you’re using something that doesn’t support the HFS+ capabilities.
It does sound like chflags() might be what’s missing from your file system, though I don’t use that either. I do use exchangedata(2) with the file reported (when the file system supports it), and likely this would not be supported by a non-native file system. Sounds a bit on the error though that for your file system it is partially supported by emulation that fails at setting flags or some such.
-
Allan Odgaard -
Christopher Creutzig -
Connor McKay