请在 2024 年 Clojure 状况调查! 中分享您的想法。

欢迎!请参阅 关于 页面以获取有关如何使用本站的一些更多信息。

0
打印

这允许打印顺序可以被 Thread.interrupt() 中断,而不是要求客户端求助于 Thread.stop()。当打印非常大的序列时,这一点特别有用。

请参阅在 https://groups.google.com/d/topic/clojure-dev/vs0RNUQXiYE/discussion 的 clojure-dev 讨论。

补丁: clj-1073-add-print-interruptibly-patch-v2.txt

方法

添加一个新的变量 print-interruptibly,类似于 print-lengthprint-dup 等。它的默认值是 false。当 true 时,在打印每个序列元素之后都会检查 (Thread/interrupted)。如果是 true,则刷新写入器并抛出 InterruptedIOException。

之前提出的替代方案中未包括 print-interruptibly,但在打印每个序列元素之后简单地始终检查 (Thread/interrupted)。基准测试表明,这可能会使打印长序列的速度慢约 10%。所提出的补丁中的方法仅在 print-interruptibly 为 true 时才会引起这种减速。当为 false 时,在基准测试中没有测量到显著减速。

10 答案

0

评论者:jafingerhut

在我的快速编写的性能测试中,我没有通过 Mac OS X 10.6.8 + Oracle/Apple JDK 1.6.0_35 来检测,我在打印大型向量时看到了 Colin 修补程序的约 9% 至 10% 的减速。

我有一个修改过的修补程序,它仅在打印完每 20 项之后调用 Thread/interrupted,使用这个版本,相对于原始代码的减速约为 3% 至 4%。

Colin,对于您的目的,偶尔检查 Thread/interrupted 是否会有任何缺点?

要运行性能测试,请编辑附件 compile.sh 以指向您的 clojure.jar,将文件 perftest-print.clj 放入同一目录,并运行 ./compile.sh。它应该在 Mac 或 Linux 上运行。

0
答者:

评论者:jafingerhut

clj-1073-allow-thread-interrupt-in-print-sequential-patch.txt(2012年9月22日)与Colin的补丁0001-Allow-thread-interruption-in-print-sequential.patch(2012年9月21日)相似,但它只在print-sequential循环中的每20(或可能是21)次检查中断状态。在我上述的性能测试中,它比当前最新的Clojure主代码慢了3-4%,而Colin的补丁在相同测试中约慢9-10%。

0
答者:

发表评论者:stu

这主要打算用于开发时使用吗?如果有可能将其实现为一个开发时特性,我并不希望为此损失性能。

0
答者:

发表评论者:trptcolin

Andy:唯一可以想到的检查Thread/interrupted不太频繁的局限性是在深层嵌套集合的情况下。

stu:是的,最初提出这个问题的原意是用于开发时使用。但我可以想象,只要有线程可以被中断(无论是通过Ctrl-C还是其他方式),都需要它。

我在性能方面的最初想法是,一旦我们已经在进行I/O,我们就不会太在意像这样的CPU绑定检查,所以我没有考虑它。我猜只有在SSD上这才会是这样。

从我自己的测试来看(使用SSD),Andy关于打印一百万个数字的基准测试比我的原始补丁的基线慢了大约一秒(12.08秒 -> 13.10秒),而与Andy的补丁相同(12.08秒 -> 11.75秒)。减少到一千个数字并没有显示出任何差异(每个版本都完成在~1.3秒左右)。增加到两百万个数字会使我的补丁比基线慢2秒,而Andy的补丁则略快于基线(某种方式)。增加到五百万个数字会使我耗尽堆空间:)

0
答者:

评论者:jafingerhut

clj-1073-add-print-interruptibly-patch-v1.txt(2012年11月8日)与Colin的补丁0001-Allow-thread-interruption-in-print-sequential.patch(2012年9月21日)有相同的思想,但它只在当一个新的变量print-interruptibly为true时检查(Thread/interrupted)。它的默认值是false。

由test.sh脚本来驱动perftest-print.clj程序的性能结果,针对Clojure 1.5-beta1和两个不同的补丁。所有运行时间均为经过的时间(秒),并按升序排序以易于比较。

执行摘要:当将< strong >print-interruptibly< /strong >设置为默认的 false 值时,性能结果与今天大致相同。将< strong >print-interruptibly< /strong >绑定到 true,性能结果如预期的那样较慢,大约与 Colin 的补丁相同。

1.5-beta1 原文件未更改
13.75 13.80 13.83 13.87 13.93

使用这个新的< strong >print-interruptibly< /strong >补丁,当< strong >print-interruptibly< /strong >
在默认的 false 值时
13.86 13.91 14.01 14.08 14.14

使用这个新的< strong >print-interruptibly< /strong >补丁,当< strong >print-interruptibly< /strong >
在打印过程中绑定到 true(因此是对 perftest-print.clj 的略微修改版本,即(绑定(链接:print-interruptibly true)
...)围绕代码的核心部分)
应用补丁 0001-Allow-thread-interruption-in-print-sequential.patch
15.29 15.44 15.45 15.62 15.63

应用
by
15.38 15.46 15.48 15.49 15.50

0
Andy 的最新补丁看起来不错,并且使 REPL 和其他可中断场景可以启用“安全”行为。我个人更希望默认启用“安全”行为,但可以理解性能问题,这让我得到了真正想要的东西。

发表评论者:trptcolin

by

0
由: halgari 制作

核实,因为听起来性能问题已经得到解决。

by

0
clj-1073-add-print-interruptibly-patch-v2.txt(2013 年 2 月 12 日)与 clj-1073-add-print-interruptibly-patch-v1.txt(2012 年 11 月 8 日)相同,除了它适用于最新的 master。

评论者:jafingerhut

by

0
由: alexmiller 制作

将问题重新归类为验证,因为 Rich 尚未验证。

by

0
参考:https://clojure.atlassian.net/browse/CLJ-1073(由 trptcolin 报告)
欢迎来到 Clojure Q&A,您可以在这里提出问题并从 Clojure 社区成员那里获得答案。
...