巨大的iTextSharp5性能评测/重构

Question

首先抱歉我的英语不好。 我做了一些iTextSharp审查和分析，发现了大量与性能相关的问题，尤其是在多线程场景中。我进行了一些大规模的重构，提高了300％的性能（从~100秒到~25秒）。一侧有太多不必要的锁，另一侧有一些愚蠢的线程错误。例如＆＃34; Image.cs第1352行和＃34;

    /// <summary>
    /// generates new serial id
    /// </summary>
    static protected long GetSerialId() {
        lock (serialId) {
            serialId = (long)serialId + 1L;
            return (long)serialId;
        }
    }

这不是线程安全的代码，因为您更改了锁定对象。让我们说2个线程（A和B）将等待锁定而另一个线程（C）处于锁定部分。所以那些A和B线程等待值＃34; 1＆＃34;但是线程C将它们改为＆＃34; 2＆＃34;。一旦A和B开始C退出锁定比赛（他们都可以在一段时间内输入一个部分，因为＆＃34; 1＆＃34;不再被锁定）。 有更好的Interlocked.Increment函数

所以我的改变

1. 将每个lock（）复制到代码中，用更有效的Interocked和ReaderWriterLockSlim替换90％
2. 因为PdfName经常用作字典键 - ＆gt;查看PdfName.GetHashCode（替换为FNV1a hashe），查看PdfName.Equals（替换为快速字节数组比较）
3. 查看并删除PdfObject构造函数中的不必要的锁

4. 替换无效的walk-over-PdfDictionary模式：

   foreach（dic.Keys中的var名称）{   var obj = dic.Get（name）; //这里有一个不需要的哈希表查找 } foreach（var kv in dic）{// PdfDictionary现在实现了IEnumerable {KeyValue}   var name = kv.Key;   var obj = kv.Value; }

5. IRandomAccessSource的一些改进。基于文件的随机源现在是线程安全且非常快，因为它使用了MemoryMapped文件而不是文件流

6. 通过全局静态委托提供我自己的ZLib压缩的能力（将托管的ZLib替换为非管理的性能提升）

不幸的是，我没有时间处理Github创建拉请求等。社区是否对我的工作感兴趣？我可以在某处上传压缩源，这样任何人都可以帮我创建拉取请求并将这些更改提交到主存储库......