反思过程中优化参数装箱

Question

目前参数装箱效率低下，原因有以下两点：
1. 当参数类型非原生类型时，进行不必要的 Class.cast(..) 调用。
2. 在装箱参数时，分配一个不必要的额外 Object 数组。

此补丁修复了这些问题，但不会改变其他行为。所有测试都通过。

Answer 1

评论人：alexmiller

有问题的示例代码？

基准测试结果？

Answer 2

评论人：mikera

嗨 alexmiller，我正在尝试改进反思的快速路径，这将涉及一大堆改变，包括 clj-1784 和我的一些其他想法。

我不认为对每一个改变进行深入讨论/基准测试都会是很有成效的。是否最好为所有这些改变创建一个新的任务，并提供对其整体影响的基准测试？

我很乐意这么做，但如果您能表明这些建议将会被接受，前提是能够展示整体改进，将会很有帮助。我不希望在没有看到 Clojure 开发者对这个领域的性能改进感兴趣的迹象的情况下浪费精力。而且我没有时间对每一个个别改变进行深入的讨论。

Answer 3

评论人：alexmiller

每个工单应识别一个特定问题，并提出有证据支持的解决方案。如果有多个问题，它们很可能以不同的速度移动。

如果您发现了一个热点，我们将很乐意去查看。但我们必须从解决问题开始，而不是仅仅说：“这里有一些变化”。如果这个变化使事情变得更好，那么您应该能够证明这一点。

Answer 4

评论人：alexmiller

我想说，我对反射问题的正确答案不仅仅是去除反射这一点表示怀疑。但直到你提供问题，我无法评价这一点。

Answer 5

评论人：mikera

问题在于，根据描述，它效率低下（因此对反射的使用用户变慢）。如果您有您想看到的其他措辞，可以提出来吗？

人们是否应该使用反射与使反射本身更快的做法无关。我同意人们在可能的情况下应使用类型提示，但许多人没有时间弄懂它/不知道如何正确操作/没有意识到正在发生这种情况，因此，任何对这些情况的改进都应该受到欢迎？

此外，您还没有回答我的问题：您是否希望将所有内容合并为单个反射性能改进工单，还是不合并？

Answer 6

评论人：alexmiller

本工单的标题是“在反射期间优化参数装箱”。这是一个解决方案，而不是问题。我希望看到的是类似“反射使用boxed args速度慢”的标题以及以一些示例代码开头的描述，以展示问题。（这些示例代码往往构成修复中应包含的测试的特别好的模板。）

然后，我想看看您的建议是如何改善问题的证据。对于性能问题，我特别希望看到在时间上的前后基准，最好是使用criterium等测试工具，这样我才能对我所获得的收益有信心。

从优先级的角度来看，我认为反射的性能不是高优先级的，因为最好的答案可能是：不要使用反射。尽管如此，我愿意考虑它，尤其是在有令人信服的例子，可能难以去除反射或者反射发生特别不明显的情况下。

关于您的问题，我们倾向于考虑个别问题，而不是“一大堆变化”，所以分开更好。

Answer 7

参考：[https://clojure.atlassian.net/browse/CLJ-1866](https://clojure.atlassian.net/browse/CLJ-1866)（由mikera报告）