Re: [Bibdesk-users] Upgrading

[FZiegler]

> On Mar 3, 2020, at 8:50 PM, Adam R. Maxwell via Bibdesk-users 
>  wrote:
> 
> On March 3, 2020 at 5:31 PM, FZiegler  wrote:
> 
>>> That would explain me seeing the same BibDesk slowdown on a new machine 
>>> running Mojave -- but alas not the (BibDesk- and LS-unrelated) problems 
>>> that started this all for me *in Yosemite* (crashes for which the shop 
>>> today said they found no hardware reason, either). Oh well.
>> 
>> 
> 
> 
> Is the slow system using APFS, and the fast one using HFS+? That might 
> explain it, too. APFS performance sucks, at least with spinning drives.


Yes APFS. Yay, another variable!

a) BibDesk 1.5.6  on Macmini8,1 running Mojave / APFS, showing icons: molasses.
b) BibDesk 1.5.6  on Macmini8,1 running Mojave / APFS, without icons: fine.
c) BibDesk (any)  on MacBookPro11,2 running High Sierra / HFS+, showing icons: 
molasses.
d) BibDesk (any)  on MacBookPro11,2 running High Sierra / HFS+, without icons: 
fine.
e) Unison 2.40.61 on MacBookPro11,2 running High Sierra / HFS+, showing icons: 
molasses.
f) Bibdesk 1.5.6  on MacBookPro11,2 running Yosemite / HFS+, showing icons: 
fine.
g) Unison 2.40.61 on MacBookPro11,2 running Yosemite / HFS+, showing icons: 
fine.

(But f|g has other problems that started me on this upgrade treadmill. Which I 
loathe, though I must acknowledge the gain in features and [elsewhere] speed. 
That’s life I guess! I’ll look if others noticed anything in Unison.)

Francois 





___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Re: [Bibdesk-users] Upgrading

[Adam R. Maxwell via Bibdesk-users]

On March 3, 2020 at 5:31 PM, FZiegler  wrote:


That would explain me seeing the same BibDesk slowdown on a new machine running 
Mojave -- but alas not the (BibDesk- and LS-unrelated) problems that started 
this all for me *in Yosemite* (crashes for which the shop today said they found 
no hardware reason, either). Oh well.




Is the slow system using APFS, and the fast one using HFS+? That might explain 
it, too. APFS performance sucks, at least with spinning drives.


-- 
adam

___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Re: [Bibdesk-users] Upgrading

[FZiegler]

> On Mar 3, 2020, at 5:12 AM, Christiaan Hofman  wrote:
> 
>> On 3 Mar 2020, at 03:12, FZiegler > > wrote:
>> 
>> Any ideas on how else to investigate would be great, but I also understand 
>> my machine may be hosed worse than I thought(*).
>> 
>> Francois
>> 
>> 
>> (*) Long story short, it has 3 partitions “OSX”, “Home” and “Empty” of which 
>> OSX had Yosemite and Empty has the recently installed & problematic High 
>> Sierra. I traditionally keep all non-factory stuff (user dir, own apps, 
>> /usr/local) in Home, and never had problems doing that. But the High Sierra 
>> install was prompted by crashes which could be hardware after all -- can a 
>> dying SSD have such effects?  
> 
> I suspect your partitioning is responsible for this slow down. But I don’t 
> know how LS interacts with partitions. Perhaps lsregister only scans the 
> current system’s partition on this OS system?


That may very well be. I just realized that Unison.app (that I use to sync my 
files to their latest versions amid backing up and switching computers...) also 
has a table view with icons that slows to a crawl, spending much time in LS: 
>.

So maybe the conclusion is that Apple no longer really supports partitioning? 
That would suck because it’s the only way I knew to test (on *one* computer) if 
a new system breaks apps. I guess the only way to find out is to wipe and try 
it all again with the drive unpartitioned.

That would explain me seeing the same BibDesk slowdown on a new machine running 
Mojave -- but alas not the (BibDesk- and LS-unrelated) problems that started 
this all for me *in Yosemite* (crashes for which the shop today said they found 
no hardware reason, either). Oh well.

I’ll try the iconForFileType: version as soon as I get a chance. Thanks again 
for all your help and commiseration! 

Francois ___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Re: [Bibdesk-users] Upgrading

[Adam R. Maxwell via Bibdesk-users]

On March 3, 2020 at 10:54 AM, FZiegler  wrote:


On Mar 3, 2020, at 1:21 PM, Adam R. Maxwell via Bibdesk-users 
 wrote:


Huh. I speculate that 32 vs 64 is a red herring, but it may be taking a 
different code path if you're linking against a different SDK. Either way, this 
is an interesting content type tree. You might use lsregister with -dump to see 
what LS thinks a .djvu file is; I wonder if you have competing UTI definitions 
for it, and that's confusing the type system?


Apple's Launch Services database is like the Windows Registry, except that it's 
undocumented, more fragile, harder to inspect, and not editable by the user :(.


But do you think it’s all due to .djvu -- not another red herring? The vast 
majority of icons in my BibDesk’s Local-Url column (when displayed) are pdfs, 
and the LS database reset that reassigned them to Preview.app already sped 
things up spectacularly -- until I scrolled to a .djvu or reassigned the pdfs 
to Skim.


Well, having Skim slow it down does throw a monkey wrench in my guess. Have you 
tried disabling the file icon preview in Finder, to see if that helps?


--
adam


 ___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Re: [Bibdesk-users] Upgrading

[FZiegler]

> On Mar 3, 2020, at 1:21 PM, Adam R. Maxwell via Bibdesk-users 
>  wrote:
> 
> Huh. I speculate that 32 vs 64 is a red herring, but it may be taking a 
> different code path if you're linking against a different SDK. Either way, 
> this is an interesting content type tree. You might use lsregister with -dump 
> to see what LS thinks a .djvu file is; I wonder if you have competing UTI 
> definitions for it, and that's confusing the type system?
> 
> Apple's Launch Services database is like the Windows Registry, except that 
> it's undocumented, more fragile, harder to inspect, and not editable by the 
> user :(.


But do you think it’s all due to .djvu -- not another red herring? The vast 
majority of icons in my BibDesk’s Local-Url column (when displayed) are pdfs, 
and the LS database reset that reassigned them to Preview.app already sped 
things up spectacularly -- until I scrolled to a .djvu or reassigned the pdfs 
to Skim.

The following is the NON-RESET database on the mini (new account using home dir 
from backup):  


> FZs-Mac-mini:~ fz$ 
> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister
>  -dump
> Checking data integrity..done.
> Status: Database is seeded.
> Status: Preferences are loaded.
> Seeded System Version: 10.14.1 (18B75)
> Seeded Model Code: Macmini8,1
> CacheGUID: CAB58D41-C8C6-4089-8E80-8A5305688E51
> CacheSequenceNum: 3272
> Date Initialized: 3/3/20, 10:43:30 AM EST (POSIX 1583250210.000)
> Path: 
> /var/folders/cz/j1f_z_2j6w7d9j58rjymfgz8gn/0/com.apple.LaunchServices-231-v2.csstore
> DB Object:  { path = 
> '/var/folders/cz/j1f_z_2j6w7d9j58rjymfgz8gn/0/com.apple.LaunchServices-231-v2.csstore'
>  }
> Store Object: <_CSStore 0x7fa3b6d01c00> { p = 0x11000, length = 
> 2904064/2901988/2708556 }
> 11000:6264736c  0200028e  43840300  e4472c00bdslCG,.
> + MEMORY USAGE +
> sizeof(Data):  100 ( 100 bytes) 
> sizeof(Table):  80 (  80 bytes) 
> sizeof(Unit):8 (   8 bytes) 
> sizeof(IdentifierCache): 4 (   4 bytes) 
> 
> ActivityTypeBinding: 16336 ( 16 KB)  1 u
> Alias:  415108 (415 KB)460 u
> Array:  128700 (129 KB)   6435 u
> ArrayData:  118192 (118 KB)   6071 u
> BindableKeyMap:  65296 ( 65 KB)  1 u
> BindingList:108788 (109 KB)   3363 u
> Bundle: 149736 (150 KB)367 u
> BundleIDBinding:  8176 (  8 KB)  1 u
> BundleNameBinding:   16336 ( 16 KB)  1 u
> BundleSignatureBinding:   4096 (  4 KB)  1 u
> Claim:   49680 ( 50 KB)   1035 u
> Container: 108 ( 108 bytes)  3 u
> DB Header:   0 (   Zero KB)  0 u
> DeviceModelCodeBinding:   8176 (  8 KB)  1 u
> ExtensionBinding:16336 ( 16 KB)  1 u
> ExtensionPoint:   1280 (  1 KB) 40 u
> ExtensionPointIDBinding:  4096 (  4 KB)  1 u
> HandlerPref:   900 ( 900 bytes)  9 u
> MIMEBinding:  8176 (  8 KB)  1 u
> NSPasteboardBinding:  4096 (  4 KB)  1 u
> OSTypeBinding:8176 (  8 KB)  1 u
> Plugin:  10800 ( 11 KB) 90 u
> PluginBundleIDBinding:4096 (  4 KB)  1 u
> PluginProtocolBinding:4096 (  4 KB)  1 u
> PluginUUIDBinding:4096 (  4 KB)  1 u
> PropertyList:   609760 (610 KB)835 u
> Service:  3328 (  3 KB) 64 u
> String: 130576 (131 KB)  1 u
> StringData: 285282 (285 KB)   7808 u
> Type:75600 ( 76 KB)   1260 u
> URLSchemeBinding: 4096 (  4 KB)  1 u
> UTIBinding:  32656 ( 33 KB)  1 u
> 
> Tables:   3176 (  3 KB) 
> Identifier caches:  397320 (397 KB) 
> All units: 2296174 (2.3 MB)  27857 u
> Collectable:193432 (193 KB) 
> Total bytes used:  2708556 (2.7 MB) 
> 





<... then at line 9652: ...>




> 
> BundleClass: kLSBundleClassApplication
> Container mount state: mounted
> bundleid:3116
>   Mach-O UUIDs:  6F297DA5-30A6-39F2-B4BC-90A0C164023B
>   Device Familie 
>   Counterpart ID 
>   sequenceNum:   3116
>   FamilyID:  0
>   

Re: [Bibdesk-users] Upgrading

[Adam R. Maxwell via Bibdesk-users]

On March 3, 2020 at 10:02 AM, FZiegler  wrote:


On Mar 3, 2020, at 11:26 AM, Adam R. Maxwell via Bibdesk-users 
 wrote:


Francois, do you have "Show icon preview" turned on in Finder's view options? I 
wonder if there's a Quick Look plugin running to generate previews. That doesn't make 
sense with the sample, which shows it wasting a lot of time in a type lookup (recursive, 
maybe?). It might be interesting to run mdls in Terminal on a .djvu file and see what the 
type tree looks like.

Yes, I turn on Show icon preview. Below is mdls on a .djvu, with proviso that I 
gave the MacBook away for hardware tests and am on an new (identically 
organized) Mac mini running Mojave.

kMDItemContentType = "com.lizardtech.djvu"
kMDItemContentTypeTree = (
"public.content",
"public.item",
"public.data",
"public.composite-content",
"com.lizardtech.djvu",
"org.djvuzone.djvulibre.djvu"
)


Huh. I speculate that 32 vs 64 is a red herring, but it may be taking a 
different code path if you're linking against a different SDK. Either way, this 
is an interesting content type tree. You might use lsregister with -dump to see 
what LS thinks a .djvu file is; I wonder if you have competing UTI definitions 
for it, and that's confusing the type system?


Apple's Launch Services database is like the Windows Registry, except that it's 
undocumented, more fragile, harder to inspect, and not editable by the user :(.

 
-- adam

___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Re: [Bibdesk-users] Upgrading

[FZiegler]

> On Mar 3, 2020, at 11:26 AM, Adam R. Maxwell via Bibdesk-users 
>  wrote:
> 
> Francois, do you have "Show icon preview" turned on in Finder's view options? 
> I wonder if there's a Quick Look plugin running to generate previews. That 
> doesn't make sense with the sample, which shows it wasting a lot of time in a 
> type lookup (recursive, maybe?). It might be interesting to run mdls in 
> Terminal on a .djvu file and see what the type tree looks like.

Yes, I turn on Show icon preview. Below is mdls on a .djvu, with proviso that I 
gave the MacBook away for hardware tests and am on an new (identically 
organized) Mac mini running Mojave.

There, what I can say so far is that my 32-bit BibDesk 1.5.6 runs fine (no 
warning here about it being ”not optimized”) but exhibits the exact same 
slowness unless I use Christiaan’s workaround to just not display the Local-Url 
column. (I won’t recompile it in 64-bit until I have the laptop back.)

Francois


FZs-Mac-mini:Walmesley.C fz$ mdls *
kMDItemContentCreationDate = 2008-11-10 05:49:04 +
kMDItemContentCreationDate_Ranking = 2008-11-10 00:00:00 +
kMDItemContentModificationDate = 2008-11-10 05:49:04 +
kMDItemContentType = "com.lizardtech.djvu"
kMDItemContentTypeTree = (
"public.content",
"public.item",
"public.data",
"public.composite-content",
"com.lizardtech.djvu",
"org.djvuzone.djvulibre.djvu"
)
kMDItemDateAdded   = 2020-03-03 16:30:55 +
kMDItemDateAdded_Ranking   = 2020-03-03 00:00:00 +
kMDItemDisplayName = "Walmesley.1753.djvu"
kMDItemDownloadedDate  = (
"2020-02-22 08:29:56 +"
)
kMDItemFSContentChangeDate = 2008-11-10 05:49:04 +
kMDItemFSCreationDate  = 2008-11-10 05:49:04 +
kMDItemFSCreatorCode   = ""
kMDItemFSFinderFlags   = 0
kMDItemFSHasCustomIcon = (null)
kMDItemFSInvisible = 0
kMDItemFSIsExtensionHidden = 0
kMDItemFSIsStationery  = (null)
kMDItemFSLabel = 0
kMDItemFSName  = "Walmesley.1753.djvu"
kMDItemFSNodeCount = (null)
kMDItemFSOwnerGroupID  = 80
kMDItemFSOwnerUserID   = 501
kMDItemFSSize  = 1523
kMDItemFSTypeCode  = ""
kMDItemInterestingDate_Ranking = 2008-11-10 00:00:00 +
kMDItemKind= "DjVu File"
kMDItemLogicalSize = 1523
kMDItemPhysicalSize= 17780736
kMDItemWhereFroms  = (

"https://ia802609.us.archive.org/18/items/analysedesmesur00walmgoog/analysedesmesur00walmgoog.djvu;,
"https://archive.org/download/analysedesmesur00walmgoog;
)

___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Re: [Bibdesk-users] Upgrading

[Adam R. Maxwell via Bibdesk-users]

Francois, do you have "Show icon preview" turned on in Finder's view options? I 
wonder if there's a Quick Look plugin running to generate previews. That doesn't make 
sense with the sample, which shows it wasting a lot of time in a type lookup (recursive, 
maybe?). It might be interesting to run mdls in Terminal on a .djvu file and see what the 
type tree looks like.___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Re: [Bibdesk-users] Upgrading

[Christiaan Hofman]

> On 3 Mar 2020, at 06:00, Adam R. Maxwell via Bibdesk-users 
>  wrote:
> 
> 
> 
>> On Mar 2, 2020, at 11:02 , Christiaan Hofman  wrote:
>> 
>> That is weird, I have no idea what is going on. It should not matter whether 
>> an app is in Applications, I see them even when they are in a temporary 
>> build location. Also the default app should nit be reset when the LS 
>> database is reset.
> 
> I thought that was the entire point of -kill and resetting the LS database? 
> In my recollection, it resets all default application bindings, which is why 
> I hate running it.
> 
> Also, I thought -[NSWorkspace iconForFile:] performance had always been 
> terrible? Why not use iconForFileType: and get a generic one?
> 
> -- 
> adam
> 


I’ll do that.

Francois, perhaps you can try out tomorrow’s nightly build to see if that works 
better for you.

Christiaan

___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Re: [Bibdesk-users] Upgrading

[Christiaan Hofman]

> On 3 Mar 2020, at 03:12, FZiegler  wrote:
> 
>> On Mar 2, 2020, at 2:02 PM, Christiaan Hofman > > wrote:
>> 
>> That is weird, I have no idea what is going on. It should not matter whether 
>> an app is in Applications, I see them even when they are in a temporary 
>> build location. Also the default app should nit be reset when the LS 
>> database is reset. There really seems to be something wrong with launch 
>> services on that system. Perhaps reinstalling Skim may help? 
>> 
>> Christiaan
> 
> 
> Reinstalling Skim helped indeed. I threw my existing 1.5.6 away from 
> /Volumes/Home/Applications/ and downloaded a new one into /Applications. 
> After that, updating the LS database *no longer* resets all pdfs to open with 
> Preview.app, and BibDesk is (mostly) snazzy again. Still bizarre:
> 
> 1) Other apps still tend to lose their icon in the LS update: 
> >; 
>  > seems to vry slowly populate 
> over time (hours). 
> 
> 2) BibDesk still slows down to molasses if I go near (e.g. open Get Info 
> window for) records whose associated file is .djvu; see: 
>  >; so should I now download a new 
> DjView.app into /Applications ? :-)
> 
> Any ideas on how else to investigate would be great, but I also understand my 
> machine may be hosed worse than I thought(*).
> 
> Francois
> 
> 
> (*) Long story short, it has 3 partitions “OSX”, “Home” and “Empty” of which 
> OSX had Yosemite and Empty has the recently installed & problematic High 
> Sierra. I traditionally keep all non-factory stuff (user dir, own apps, 
> /usr/local) in Home, and never had problems doing that. But the High Sierra 
> install was prompted by crashes which could be hardware after all -- can a 
> dying SSD have such effects?  
> 

I suspect your partitioning is responsible for this slow down. But I don’t know 
how LS interacts with partitions. Perhaps lsregister only scans the current 
system’s partition on this OS system?

Christiaan

___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Re: [Bibdesk-users] Upgrading

[Christiaan Hofman]

AFAIK, whenever I run lsregister it keeps my default app binding. But
perhaps that depends on the OS version. Also, on  Catalina I have to reboot
after running lsregister, unlike for earlier systems.

Christiaan

Op di 3 mrt. 2020 06:18 schreef Adam R. Maxwell via Bibdesk-users <
bibdesk-users@lists.sourceforge.net:

>
>
> > On Mar 2, 2020, at 11:02 , Christiaan Hofman  wrote:
> >
> > That is weird, I have no idea what is going on. It should not matter
> whether an app is in Applications, I see them even when they are in a
> temporary build location. Also the default app should nit be reset when the
> LS database is reset.
>
> I thought that was the entire point of -kill and resetting the LS
> database? In my recollection, it resets all default application bindings,
> which is why I hate running it.
>
> Also, I thought -[NSWorkspace iconForFile:] performance had always been
> terrible? Why not use iconForFileType: and get a generic one?
>
> --
> adam
>
>
>
> ___
> Bibdesk-users mailing list
> Bibdesk-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bibdesk-users
>
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users