脚轮性能问题

发布于 2024-07-07 06:25:03 字数 350 浏览 9 评论 0原文

我们最近从版本 0.9.5.3 升级到 Castor 1.2,我们注意到在 XML 上调用 unmarshal 时性能急剧下降。 在这两种情况下,我们都将解组到由castor 生成的java 类。 相比之下,使用相同的 XML,XML 解组调用的时间过去大约需要 10-20 毫秒,现在大约需要 2300 毫秒。 在我们的新 Castor 实现中,是否有一些明显的我可能丢失的东西,也许是在我丢失的属性文件中,或者我应该开始考虑恢复到旧版本? 也许在 java 类文件生成过程中有些东西杀死了 unmarshal 调用? 如果有充分的理由放弃 Castor 而选择其他产品,我也可能会考虑 Castor 的替代品。 我们在 weblogic 服务器中使用 java 1.5。

We recently upgraded to Castor 1.2 from version 0.9.5.3 and we've noticed a dramatic drop in performance when calling unmarshal on XML. We're unmarshaling to java classes that were generated by castor in both cases. For comparison, using identical XML the time for the XML unmarshal call used to take about 10-20ms and now takes about 2300ms. Is there something obvious I might be missing in our new castor implementation, maybe in a property file that I missed or should I start looking at reverting to the old version? Maybe there was something in the java class file generation that is killing the unmarshal call? I might also consider Castor alternatives if there were a good reason to drop it in favor of something else. We're using java 1.5 in a weblogic server.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

我爱人 2024-07-14 06:25:03

通过使用带有 .castor.cdr 文件的castor 1.0.5,我们遇到了非常严重的性能问题(解组需要几秒钟,而过去需要几毫秒)。

.castor.cdr 生成的文件似乎包含旧的/错误的值(不存在的类型和描述符)。 删除该文件中的相关行后,一切恢复正常。

希望这可以帮助任何有同样问题的人!

We had very serious performance issues by using castor 1.0.5, with .castor.cdr file (a few seconds to unmarshal, whereas it took milliseconds by the past).

It appeared that the .castor.cdr generated file contained old/wrong values (inexisting types and descriptor). After deleting the incriminated lines in this file, all was back to normal.

Hope this could help for anyone who have the same problem!

夏末染殇 2024-07-14 06:25:03

您可能需要考虑使用 JiBX 代替。 它比 Castor 快得多(在我进行切换的一个项目中快了 9 倍),而且更干净。

编辑:另请参阅我对此相关问题的答案

You might want to consider using JiBX instead. It is considerably faster than Castor (9x faster on one project where I made the switch), and cleaner.

EDIT: See also my answer to this related question.

汐鸠 2024-07-14 06:25:03

我们最终恢复到 Castor 版本 0.9.5.3,并且在我们从新的 XSD 重新生成 java 类后,性能又回升了。 我不确定为什么生成的 java 之间会有如此大的差异,但 1.2 类在解组时慢了大约 2 个数量级。

**编辑:**看起来通过创建 ClassDescriptorResolvers/mapping 文件并关闭验证我们也可以提高性能,但由于我们使用模式生成过程创建了大约 1000 个对象,从成本角度来看这实际上并不可行。

We wound up reverting to Castor version 0.9.5.3 and the performance jumped back up after we regenerated the java classes from the new XSD's. I'm not sure why exactly there's such a big difference between the resulting java but the 1.2 classes were about 2 orders of magnitude slower when unmarshaling.

**EDIT:**It looks like by creating ClassDescriptorResolvers/mapping file and turing off validation that we could improve the performance also but since we create about 1000 objects with the schema generation process this isn't really viable from a cost perspective.

初心 2024-07-14 06:25:03

我也遇到这个问题,在生成基本的客户/地址 XML 集时,大约需要 3 秒才能生成包含 74 个客户的文档。

恢复到 1.0.4(用于测试)会看到返回到 1.4 秒,

但是手动滚动 XML 会在 40 毫秒以下看到输出。我知道框架会增加一些开销,但一定有什么原因导致了这种情况。

Castor 上运行过任何分析吗?

我会按照 Dan 的建议去调查 JiBX。

I too have this issue, when generating a basic customer/address set of XML it takes around 3s to generate a document including 74 customers.

Reverting to 1.0.4 (for testing) sees this return to 1.4s,

But hand rolling the XML sees the output at under 40ms.. I know the frameworks add some overhead, but there must be something causing this.

Has there been any profiling run on Castor?

I'll go investigate JiBX as suggested by Dan.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文