我试图用ObjectIDGenerator在C＃中生成序列化过程中一个唯一的ID，但是，这个类是不是在XBOX360或Windows Phone 7的.NET框架（他们使用.NET的压缩版本）提供。我实现了使用对象来的Int64的字典版本，并能够得到一个全功能的版本了，不过，性能并不理想。我序列化对象数万的量级，目前这是保存/载入性能的最大瓶颈。使用实际的.NET实现在PC上花费约0.3秒，序列化约20000对象。使用我的实现，大约需要6秒钟。

I was attempting to use ObjectIDGenerator in C# to generate a unique ID during serialization, however, this class is not available in the XBox360 or Windows Phone 7 .NET frameworks (they use a compact version of .NET). I implemented a version using a dictionary of Object to Int64 and was able to get a fully working version up, however, the performance is unsatisfactory. I'm serializing on the order of tens of thousands of objects, and currently this is the greatest bottleneck in save/load performance. Using the actual .NET implementation on PC it takes about 0.3 seconds to serialize about 20,000 objects. Using my implementation, it takes about 6 seconds.

在分析，我发现，重量级是.TryGetValue和。新增的字典（这是有道理的，因为它的索引和增加了散列映射）。更重要的是，虚拟平等的经营者被称为，而不是简单地比较引用，所以我实现了一个的IEqualityComparer只有使用的ReferenceEquals（这导致了速度增加）。

In profiling, I found that the heavy hitters were .TryGetValue and .Add on the dictionary (which makes sense since it's both indexing and adding to the hash map). More importantly, the virtual equality operator was being called instead of simply comparing references, so I implemented an IEqualityComparer that only used ReferenceEquals (this resulted in a speed increase).

有没有人见识到一个更好的实施ObjectIDGenerator的？感谢您的帮助！

Does anyone have an insight into a better implementation of ObjectIDGenerator? Thanks for your help!

我的实现： http://pastebin.com/H1skZwNK

另外要注意，分析的结果说，对象比较/的ReferenceEquals仍是瓶颈，以43,000,000的命中次数。我不知道是否有一种方法来存储沿边此对象的数据，而无需看它在一个哈希表...

Another note, the results of profiling says that the object comparison / ReferenceEquals is still the bottleneck, with a hit count of 43,000,000. I'm wondering if there's a way to store data along side this object without having to look it up in a hash map...

推荐答案

是否有可能使用的Int32 Id属性/手柄的每个对象，而不是对象？这可能无补于事。它看起来就像你分配一个ID类型号的每个对象，无论如何，只有你，然后查找基于对象的参考，而不是标识。你能坚持的对象ID（你的的Int64 ）的每个对象中，让你的字典成词典＆LT; Int64类型，对象＆gt; 呢？

Is it possible to use an Int32 Id property / handle for each object rather than Object? That may help things. It looks like you're assigning an Id type number to each object anyway, only you're then looking up based on the Object reference instead of the Id. Can you persist the object id (your Int64) within each object and make your dictionary into Dictionary<Int64, Object> instead?

您可能也想看看 SortedDictionary＆LT; TKEY的，TValue＆GT; 或排序列表＆LT; TKEY的，TValue＆GT; 执行更好或更坏。但是，如果你的主要瓶颈是在你的的IEqualityComparer ，这些可能帮助不大。

You might also want to see if SortedDictionary<TKey, TValue> or SortedList<TKey, TValue> perform better or worse. But if your main bottleneck is in your IEqualityComparer, these might not help very much.

更新

细算 ObjectIDGenerator 类的API，我可以看到你为什么不能做什么，我建议在第一次;你创建的ID！

After looking at the ObjectIDGenerator class API, I can see why you can't do what I advised at first; you're creating the ids!

ObjectIDGenerator 似乎是手动执行自己的哈希表（它分配一个 [对象] 和并行长[] 并调整它们的加入对象）。它还使用 RuntimeHelpers.GetHash code（对象） 来计算其哈希值，而不是一个的IEqualityComparer 这可能是一个很大的促进你的PERF因为它总是调用 Object.GetHash code（）并没有做对派生类型的虚拟呼叫（或你的案件的接口调用与的IEqualityComparer ）。

ObjectIDGenerator seems to be manually implementing its own hash table (it allocates an object[] and a parallel long[] and resizes them as objects are added). It also uses RuntimeHelpers.GetHashCode(Object) to calculate its hash rather than an IEqualityComparer which may be a big boost to your perf as its always calling Object.GetHashCode() and not doing the virtual call on the derived type (or the interface call in your case with IEqualityComparer).

您可以看到源自己通过微软共享源代码计划：

You can see the source for yourself via the Microsoft Shared Source Initiative: