我正在尝试生成一个基于大型工作簿的报表,其中包含100、12000和12000行的3个支持工作表以及一个基于最终公式的最终输出表,这些公式最终基于每100行显示约120个实体。 我生成一个模板范围,并在粘贴每个新范围后复制并粘贴它替换实体ID单元格。 它工作正常,但我注意到IIS Express进程中的内存使用量约为500mb,并且也占用了100%的处理器使用率。
是否有任何以这种方式生成工作簿的准则?
我正在尝试生成一个基于大型工作簿的报表,其中包含100、12000和12000行的3个支持工作表以及一个基于最终公式的最终输出表,这些公式最终基于每100行显示约120个实体。 我生成一个模板范围,并在粘贴每个新范围后复制并粘贴它替换实体ID单元格。 它工作正常,但我注意到IIS Express进程中的内存使用量约为500mb,并且也占用了100%的处理器使用率。
是否有任何以这种方式生成工作簿的准则?
至少就内存利用率而言,可能会与Excel进行一些比较,以比较利用多少内存来简单地打开结果工作簿。 例如,如果要同时在Excel和“ SpreadsheetGear 2012 for Windows”应用程序(“开始”菜单下的SpreadsheetGear文件夹中提供)中打开最终报告,则任务管理器会针对这些应用程序在内存方面进行哪些测量消费? 这可能提供一些洞察力,使您了解在实际的报告构建过程中看到的内存利用率是否异常高(例程是否有很多额外的开销?),或者仅在生成的工作簿规模大的情况下才是典型的。
就CPU利用率而言,这一点很难确定,并且肯定取决于您的硬件以及代码中的实现细节。 如果您有此工具,那么对您的例程运行VS Profiler肯定很有趣。 一般来说,CPU时间可能分为两大类:用于“构建”工作簿的CPU周期和用于“计算”工作表的CPU周期。 更好地确定其中哪一个主导CPU可能会有所帮助。 一种可能的方法是,如果可能的话,请确保在实际完成工作簿生成之前不会进行计算。 实际上,避免任何不必要的计算可能会加快处理速度……但这取决于工作簿。 您可以通过设置IWorkbookSet来避免计算。 在手动完成 计算之前 ,不要调用IWorkbook的任何“计算”方法( Calculate / CalculateFull / CalculateFullRebuild ),直到您熟悉此过程。 如果您也无法访问Profiler,则可以设置一些计时器,Console.WriteLines并监视任务管理器,以查看CPU在例程的不同部分如何波动。 运气好的话,您也许能够更好地隔离例程中花费最多时间的部分。