之前有一个问题在比较Clojure和Scala的速度时得到了成功的回答，但是将这些相同的技术应用于以下代码仍然比等效的Scala代码慢25倍以上。这是在Java1.8上比较Clojure 1.6.0和Leiningen 2.5.0。0_40Scala 2.11.6：
比较不使用REPL，而是使用Leiningen"run"命令，在使用Leiningen"uberjar"命令生成独立的"jar"文件后，直接从java运行时以大约相同的速度运行。
微基准测试在数组内进行位操作的速度，这是一些低级别任务的典型类型，例如加密或压缩或素数筛选。为了获得合理的测量间隔并避免JIT开销破坏结果，基准测试运行相同的循环1000次。
Clojure代码如下：
(ns test-cljr-speed.core
(:gen-class))
(set! *unchecked-math* true)
(set! *warn-on-reflection* true)
(defn testspeed
"test array bit manipulating tight loop speeds."
[]
(let [lps 1000,
len (bit-shift-left 1 12),
bits ^int (int (bit-shift-left 1 17))]
(let [buf ^ints(int-array len)]
(letfn [(doit []
(loop [i ^int (int 0)]
(if (< i bits)
(let [w ^int (int (bit-shift-right i 5))]
(do
(aset-int ^ints buf w ^int (int (bit-or ^int (aget ^ints buf w)
^long (bit-shift-left 1 ^long (bit-and i 31)))))
(recur (inc i)))))))]
(dorun lps (repeatedly doit))))))
(defn -main
"runs test."
[& args]
(let [strt (System/nanoTime),
cnt (testspeed),
stop (System/nanoTime)]
(println "Took " (long (/ (- stop strt) 1000000)) " milliseconds.")))
它产生以下输出：
Took 9342 milliseconds.
我认为这个问题与访问缓冲区数组的反射有关，但已经按照建议应用了各种类型提示，似乎找不到它。
可比的Scala代码如下：
object Main extends App {
def testspeed() = {
val lps = 1000
val len = 1 << 12
val bits = 1 << 17
val buf = new Array[Int](len)
def doit() = {
def set1(i: Int): Unit =
if (i < bits) {
buf(i >> 5) |= 1 << (i & 31)
set1(i + 1)
}
set1(0)
}
(0 until lps).foreach { _ => doit() }
}
val strt = System.nanoTime()
val cnt = testspeed()
val stop = System.nanoTime()
println(s"Took ${(stop - strt) / 1000000} milliseconds.")
}
它产生以下输出：
Took 365 milliseconds.
做同样的工作，速度超过25倍！！！
我已经打开了反射警告标志，似乎没有任何Java反射，更多的提示会有所帮助。也许我没有正确打开一些优化设置（也许在莱宁根的项目文件中设置？），因为它们很难在互联网上找到；对于Scala，我已经关闭了所有调试输出并启用了编译器“优化”标志，这做了一些改进。
我的问题是“是否可以为这种类型的应用程序做些什么来使Clojure以与Scala速度更接近的速度运行？”。
为了缩短任何错误的猜测，是的，该数组确实被其他一系列测试确定的所有二进制数组多次填充，不，Scala除了一个循环之外没有优化所有循环。
我对讨论这两种语言的比较优点不感兴趣，但我只想知道如何生成合理优雅的Clojure代码，在一点一点的基础上以至少十倍的速度完成相同的工作（不是简单的数组填充操作，因为线性填充只是代表更复杂的任务，如素数剔除）。
使用JavaBitSet没有问题（但并非所有算法都只适用于一组布尔值），使用Java整数数组和Java类方法访问它也不太可能，但应该能够使用Clojure“本机”数组类型而没有这些性能问题。
首先，您的类型提示不会影响Clojure代码的执行时间，并且在我的机器上，更新的版本不是改进：
user=> (time (testspeed))
"Elapsed time: 6256.075155 msecs"
nil
user=> (time (testspeedx))
"Elapsed time: 6371.968782 msecs"
nil
您正在执行许多不需要的类型提示，并且将它们全部剥离实际上会使代码更快：
(defn testspeed-unhinted
"test array bit manipulating tight loop speeds."
[]
(let [lps 1000,
len (bit-shift-left 1 12),
bits (bit-shift-left 1 17)]
(let [buf (int-array len)]
(letfn [(doit []
(loop [i (int 0)]
(if (< i bits)
(let [w (bit-shift-right i 5)]
(do
(aset buf w (bit-or (aget buf w)
(bit-shift-left 1 (bit-and i 31))))
(recur (inc i)))))))]
(dorun lps (repeatedly doit)))))))
user=> (time (testspeed-unhinted))
"Elapsed time: 270.652953 msecs"
我突然想到，强制i对recur进行int可能会加快代码的速度，但实际上会减慢代码的速度。考虑到这一点，我决定尝试从代码中完全删除int，看看性能方面的结果是什么：
(defn testspeed-unhinted-longs
"test array bit manipulating tight loop speeds."
[]
(let [lps 1000,
len (bit-shift-left 1 12),
bits (bit-shift-left 1 17)]
(let [buf (long-array len)]
(letfn [(doit []
(loop [i 0]
(if (< i bits)
(let [w (bit-shift-right i 5)]
(do
(aset buf w (bit-or (aget buf w)
(bit-shift-left 1 (bit-and i 31))))
(recur (inc i)))))))]
(dorun lps (repeatedly doit)))))))
user=> (time (testspeed-unhinted-longs))
"Elapsed time: 221.025048 msecs"
性能提升相对较小，所以我使用标准库库来获得准确的差异微基准：
user=> (crit/bench (testspeed-unhinted))
WARNING: Final GC required 2.2835076167941852 % of runtime
Evaluation count : 240 in 60 samples of 4 calls.
Execution time mean : 260.877321 ms
Execution time std-deviation : 18.168141 ms
Execution time lower quantile : 251.952111 ms ( 2.5%)
Execution time upper quantile : 321.995872 ms (97.5%)
Overhead used : 15.568045 ns
Found 8 outliers in 60 samples (13.3333 %)
low-severe 1 (1.6667 %)
low-mild 7 (11.6667 %)
Variance from outliers : 51.8061 % Variance is severely inflated by outliers
nil
user=> (crit/bench (testspeed-unhinted-longs))
Evaluation count : 300 in 60 samples of 5 calls.
Execution time mean : 232.078704 ms
Execution time std-deviation : 24.828378 ms
Execution time lower quantile : 219.615718 ms ( 2.5%)
Execution time upper quantile : 297.456135 ms (97.5%)
Overhead used : 15.568045 ns
Found 11 outliers in 60 samples (18.3333 %)
low-severe 2 (3.3333 %)
low-mild 9 (15.0000 %)
Variance from outliers : 72.1097 % Variance is severely inflated by outliers
nil
所以最终的结果是，你可以通过删除你的类型提示来获得巨大的加速（因为代码中所有关键的东西都已经完全明确了类型），并且你可以通过从int切换到long（至少在我的64位英特尔机器上）来获得一个小小的改进。
我将回答我自己的问题，以帮助可能正在与同样问题作斗争的其他人：
在仔细阅读了另一个问题的答案后，我无意中发现了这个问题：“aset”很好；“aset-int”（以及所有其他专门形式的“aset-？”）不是，并且没有多少类型提示有帮助。
在根据@noisesmith的回答编辑的测试过程的以下代码中，我所改变的只是使用“long数组”（“int数组”也可以，只是速度不太快）并使用“aset”而不是“aset-long”（或“aset-int”用于“int-array”）并消除了所有类型提示：
(set! *unchecked-math* true)
(defn testspeed
"test array bit manipulating tight loop speeds."
[]
(let [lps 1000,
len (bit-shift-left 1 11),
bits (bit-shift-left 1 17),
buf (long-array len)]
(letfn [(doit []
(loop [i (int 0)]
(if (< i bits)
(let [w (bit-shift-right i 6)]
(do
(aset buf w (bit-or (aget buf w)
(bit-shift-left 1 (bit-and i 63))))
(recur (inc i)))))))]
(dorun lps (repeatedly doit)))))
结果它产生以下输出：
Took 395 milliseconds.
使用“aset-long”而不是“aset”，输出为：
Took 7424 milliseconds.
加速了近19倍。
现在这只是比使用Int数组的Scala代码稍微慢一点（Scala比使用Long数组快），但这在某种程度上是可以理解的，因为Clojure没有读/修改/写原语作为|=，而且编译器似乎不够聪明，无法看到读/修改/写操作是上面代码中隐含的。
但是，仅慢百分之几是完全可以接受的，这意味着对于这种类型的应用程序，性能不是在Scala或Clojure之间进行选择的标准。
这个解决方案没有意义，因为“aset-？”的专门版本应该只是调用“aset”的重载情况，但是似乎有一个问题/bug影响了它们的性能，至少在当前版本1.6.0中是这样。
