Your comments

Many thanks, Lazlo! I've been using Peek since then with some workarounds, and I love how you keep improving it. :)

Hi Lazlo, thank you for a detailed reply, it was helpful. Your explanation provides a likely scenario, and I'll invest in more RAM and a stronger CPU soon, the combination of which may improve similar Fbx-related lags among other things. 

"I wonder if they are optimized or made to be compatible for Unity"

They're standard mid-poly Genesis 8 characters, but with loads of 4096x4096 texturing. Granted, Unity doesn't "like" newer Daz characters out of the box, which may be a big part of the problem. In any case, thank you for having investigated it. I'll continue using Peek with or without these Fbx's because it's a great tool.

Hi Lazlo, thanks for investigating the memory leak. The error occurs with or without Preview Icons & Probe checked.
I just did a fresh project with only Peek installed, and using only 4 large fbx's (with calculated normals, humanoid rig, and extracted materials in order to simulate real-world usage). There is no leak and no editor lag. This suggests that it is the actual volume of fbx's that breaks Peek, not the mere presence of a few fbx's in the folders. 

In any case, I provide a link to one of my self-made Daz3D fbx's. But a single fbx will not trigger the error.!qtkiBCRT!uvzAITn_ggtJ7T8K2dYqc4U745n78j0DS4RFeOa1P8c

Hi Hasan, thanks.

1. There are about 22 fbx's in the folder.

2. Some DAZ fbx's are actually 100Mb large, most are about 50Mb.

3. I don't know which files cause the leak: the editor is unresponsive as soon as I enter the folder.

4. VS2019 and Total Commander are normally on in the background, but the same happens without them.

It happens with a folder with complex fbx's such as DAZ characters as shown. Again, it resolves when Peek's uninstalled.

TypeLoadException: Could not resolve type with token 01000084 (from typeref, class/assembly UnityEngine.AssemblyIsEditorAssembly, UnityEditor, Version=, Culture=neutral, PublicKeyToken=null)

System.MonoCustomAttrs.IsDefined (System.Reflection.ICustomAttributeProvider obj, System.Type attributeType, System.Boolean inherit) (at <567df3e0919241ba98db88bec4c6696f>:0)

System.Reflection.Assembly.IsDefined (System.Type attributeType, System.Boolean inherit) (at <567df3e0919241ba98db88bec4c6696f>:0)

System.Attribute.IsDefined (System.Reflection.Assembly element, System.Type attributeType, System.Boolean inherit) (at <567df3e0919241ba98db88bec4c6696f>:0)

System.Attribute.IsDefined (System.Reflection.Assembly element, System.Type attributeType) (at <567df3e0919241ba98db88bec4c6696f>:0)

Ludiq.PeekCore.Codebase.IsEditorAssembly (System.Reflection.Assembly assembly) (at Assets/Ludiq/Ludiq.PeekCore/Editor/Reflection/Codebase.cs:229)

Ludiq.PeekCore.Codebase.IsEditorDependentAssembly (System.Reflection.Assembly assembly) (at Assets/Ludiq/Ludiq.PeekCore/Editor/Reflection/Codebase.cs:247)

Ludiq.PeekCore.Codebase.IsRuntimeAssembly (System.Reflection.Assembly assembly) (at Assets/Ludiq/Ludiq.PeekCore/Editor/Reflection/Codebase.cs:242)

Ludiq.PeekCore.Codebase..cctor () (at Assets/Ludiq/Ludiq.PeekCore/Editor/Reflection/Codebase.cs:40)

Rethrow as TypeInitializationException: The type initializer for 'Ludiq.PeekCore.Codebase' threw an exception.

Ludiq.PeekCore.PluginContainer.Initialize () (at Assets/Ludiq/Ludiq.PeekCore/Editor/Plugins/PluginContainer.cs:110)

Ludiq.PeekCore.PluginContainer+<>c.<.cctor>b__0_0 () (at Assets/Ludiq/Ludiq.PeekCore/Editor/Plugins/PluginContainer.cs:31)

UnityEditor.EditorApplication.Internal_CallDelayFunctions () (at C:/buildslave/unity/build/Editor/Mono/EditorApplication.cs:312)

Same here, and it's a biggie. The 2 tools are clearly sharing some functionality, but they shouldn't render each other unusable.
Unsurprisingly, it also happens on 2019.2.15