Waaaaaay too slow

works faster, still nowhere close to 1.7.10… thanks

Hello Darwin,

I have an exact same issue.
Also, unchecking the ‘folders on top’ option doesn’t solves it for me - it looks like the TotalFinder becomes faster without it (switching between folders, selection, going in and out of folders seem to work faster), but the tab creation/deletion/moving and switching between them is still very slow (just incomparable to the native Finder operation).

I’ve installed the 1.7.14 you’ve provided here - it seems it’s faster with ‘folders on top’ option checked, but the tabs are still very laggy.

Here’s the system info:
OS: OS X 10.11.4 (15E65) - El Capitan
Model: MacBook Air 2013
Model ID: MacBookAir6,2
CPU: Intel Core i7
CPU speed: 1,7 GHz
Amount of CPUs: 1
Amount of CPU cores: 2
L2 cache (per core): 256 КБ
L3 cache: 4 МБ
RAM: 8 ГБ

Here’re the logs I see in my console when I’m switching between folders (on the side panel of the TotalFinder):
https://dl.dropboxusercontent.com/u/3673793/total_finder.log

Note, that there wasn’t any such logs when I was using v1.7.12

Thanks for the log. Your iconservicesagent is very upset about something, and that’s making quicklookd mad.

I suggest clearing out your icon cache and rebooting.
(these steps apply to El Capitan as well)

I’m also curious, do you have any apps/plugins installed which “badge” your Finder icons, such as Dropbox, OneDrive, etc?

Hi Steve,

Done. No luck.

Yep, I’m using Dropbox.
But I don’t think it’s pertinent - what I’m seeing now is that these logs happen when I’m visiting new folder (‘new’ here means the folder I haven’t visited after I cleared the icon cache as you’ve suggested).

Also, there’re other types of log messages that are thrown every time I look through a Finder window (not necessary visit by getting into from another folder) on a folder with the particular set of files - to this moment I’ve spotted this for *.mkv, *.wmv, and *.zip
This means I can CMD+Tab to browser, then CMD+Tab back to the Finder window with such files and this causes the logs to appear.
The logs actually tell which files posed some problem for Finder’s Quick Look.

Here’s the sample folder structure for which I can observe such behavior
—> /Users/aismagilov/Movies/Learning:
/Cisco Nexus arch
/Multicast
020 - ASA Network Address Translation (NAT) part 1.mp4
021 - ASA Network Address Translation (NAT) part 2.mp4
009 - 802.1q Tunneling, Layer 2 Protocol Tunneling, EtherChannel over 802.1q Tunneling.mov
03_06042012_building_scalable_data_centers.wmv
065. Redistribution case 1.mkv
066. Redistribution case 2.mkv
067. Redistribution case 3.mkv
076. BGP NLRI Origination.mkv
077. BGP Bestpath Selection.mkv
132. Congestion Management.mkv
133. Congestion Avoidance.mkv
134. Traffic Shaping.mkv
135 Traffic Policing.mkv

From the logs I can tell that the problem is with files the QuickLook can’t perform the quick look :slight_smile: These are *.mkv and *.wmv for example. Note, that there’re no such logs for *.mov which QuickLook can open.

The new logs are: https://dl.dropboxusercontent.com/u/3673793/total_finder_12.05.2016.log

Any suggestions where to move from this?

Same problem here. I have freshly installed OSX and Total Finder 1.7.12 and switching between folders are 2-3x slower.

Version 1.7.10 didn’t had that problem, but had other critical bugs when selecting files and folders and having selection to drop.

Is there is any way to activate only Folders on Top option and disable everything else about Total Finder?

Thanks

Guys,

Any news out there?

Yes, TotalFinder is highly modular (inside), so only what’s needed should get loaded. Have you tried just disabling everything except that “Folder on Top” checkbox?

Guys,

I really waiting for your comments on this issue.
It’s start to look like you simply ignore me.

I’m sorry you fell ignored, I promise that wasn’t my intention. I’ve only been very slowly getting up to speed with these products.

I have not been able to reproduce this issue. What locale (language) are you running?

My product SizeUp has an issue that currently only affects 2 users running Russian locale. My product Tickets crashes on launch for users of Polish locale. Two ridiculously strange bugs, but it has shown that I can’t assume anything when trying to reproduce an issue.

Thank you dude. that actually solves the problem.