CACHE_PATH 文件如果太大，Reading Cache 会很慢。有什么办法优化一下吗？

[Lingchen218]

No description provided.

[Lingchen218]

serializedGuid = (List) bf.Deserialize(fs);
这里转换比较慢

[Lingchen218]

这个方法是不是要换一下？

[networm]

你可以自己优化，弄好后提个 Pull Request

[Lingchen218]

你可以自己优化，弄好后提个 Pull Request

大佬，有什么思路吗？

[Lingchen218]

MemoryPack 这个序列化 ，可以吗？还有一个MessagePack ，这两个

[networm]

打开 Profiler，开启 Deep Profile，然后执行一次，看看到底哪个方法过于耗时，分析问题在哪。

[networm]

如果是反序列化太耗时，可以使用 FlatBuffers

[Lingchen218]

如果是反序列化太耗时，可以使用 FlatBuffers

Google.FlatBuffers 安装不上，目标框架是 unity3.5 .net full Base Class Libraries ，这个要换吗？

[networm]

搜下别人是如何集成 FlatBuffers 的

[Lingchen218]

我用 FlatBuffers 好了，缓存文件 56M ，反序列化，感觉比较慢，不知道是不是我的方法不对，56M一般反序列号要多久？

[networm]

56M 太大了，想办法改下数据结构之类的先压缩到 5M

[Lingchen218]

我用的是你的序列化的结构，总共三个，两个字符串数组，一个int[] List ,存储的，，一个 字符串数组大概56w个 字符串

[Lingchen218]

serializedGuid 和serializedDependencyHash 是list ，然后就是 serializedDenpendencies 是int[] List

[networm]

把所有的 guid hash path 去重后保存为数组，引用的地方改为使用数组下标

[Lingchen218]

好，我试试

[Lingchen218]

我结构还没优化，但是换成了c++ dll 来读取，快了很多 ，但是unity 有一些抱错，不知道是什么情况，我已经fork 仓库，你看可以看看

[networm]

先优化结构，暂时没必要上C++，不然跨平台麻烦。

[networm]

结构看起来不需要优化，56M大小的东西也不是特别大，看看 flatbuffers 卡在哪儿了。C++ 的问题自己处理。

[Lingchen218]

c# 的 flatbuffers ，不是卡，是反序列化字符串数组的时候，效率慢，要化很久时间，用c++ 的 flatbuffers 就很快就遍历完了

[networm]

自行处理报错

[Lingchen218]

没有报错，就是c# for 太慢了

[Lingchen218]

c++ 也没有看到报错，就是让你看看，有没有什么问题，我这边看是没有问题的

[Lingchen218]

https://github.com/user-attachments/assets/03fc0bc2-df2d-4ddb-8302-b9f315c2216e
我用c++ 把缓存都读取出来了，然后放在c# 里面跑，速度又慢了，看下这段视频，从20秒开始看，确实是for 太慢了

[networm]

每一千次调用一次显示canceldialog方法就可以

[networm]

重点不是读取文件，而是将文件内容变成c#内存对象，所以才需要c#版本flatbuffers

[networm]

重点不是读取文件，而是将文件内容变成c#内存对象，所以才需要c#版本flatbuffers

你现在可以先不管这个，主要看看那块为什么卡，使用 profiler

[Lingchen218]

你看那个视频了吗？就是在for 赋值的时候慢，

[Lingchen218]

我把那个赋值 注释了，就很快就过去了

[Lingchen218]

重点不是读取文件，而是将文件内容变成c#内存对象，所以才需要c#版本flatbuffers

现在应该已经是c#的内存对象了

[Lingchen218]

重点不是读取文件，而是将文件内容变成c#内存对象，所以才需要c#版本flatbuffers

就是 c#版的 flatbuffers 读取转换成c#的对象慢，所以我才换成c++ 的

[Lingchen218]

UpdateReferenceInfo 函数中references 变量是list 判断是否包含的耗时比较高，换 HashSet 就好了，UpdateReferenceInfo耗时从111秒，降低到了0.2秒，看看 dependencies 能不能也换成 HashSet ？

[networm]

那你自己尝试下吧

[Lingchen218]

没有问题了
70多万的资源
70M的文件几秒钟就读出来了。
我首次导入的时候花了将近快两个小时。

刷新引用时大概用了几分钟

[Lingchen218]

Assets/Find References In Project 右键点击这个的时候，会有几秒的白屏，好像是UpdateAssetTree() 函数中的CreateTree会慢，导致白屏，这个有啥优化的办法吗？我看 Profiler 没看明白

[networm]

先通过注释代码确定问题代码在哪儿，再去排查。

[Lingchen218]

assets 下右键，遍历所有的时候，UpdateSelectedAssets函数中 Directory.Exists(AssetDatabase.GUIDToAssetPath(guid)，69万数据，如果只是单纯的调用 GUIDToAssetPath(guid) 大概5秒钟， 如果在去判断 路径是否是文件夹， 就是大概 17.8秒钟 ，翻了3倍多时长

[networm]

第一，去掉所有的 IO 调用，包括 Directory.Exists File.Exists，实在去不掉可以在启动前获得一次整个 Assets 目录结构缓存起来
第二，缓存 GUIDToAssetPath 的结果到 Dictionary 中，后续从缓存拿结果

[Lingchen218]

如果第一次在编辑器启动加载的时候，来遍历整个 Assets 目录结构缓存起来是存到内存中 吗？ 还是序列化存到磁盘中？
但是在play 游戏的 结束后，这个Dictionary视乎会被清空，需要重新遍历 ，或者读取 编辑器启动时保存的磁盘中的序列化文件

[networm]

看你自己需求，根据实际情况选择。