基准测试协议
该基准包括解析和验证存储在文件的JSON对象. 这些数据是从 the Last.fm Dataset 抽取。JSON的结构已经被修改了一下,便于解析 (使用非常棒的 jq). 代码托管在 这里。
通过使用一系列的scala的计量基准测试进行性能测量. 这两个API都使用Jackson 解析JSON。
结果 基准用5000到10000的JSON对象解析并且验证所花费的时间来测量。在两个不同的场景进行测试:
这是结果。较低的执行时间性能更好。 
让人惊讶的是,Scala的API快很多!
Scala的API相比比Java 的API,明显更快。 有无效字段将极大地影响Java API中的性能,而对Scala这边的影响不大。
基准测试不重要 那么我们学到了什么呢?
我们学到了在这特殊设置下,一个用Scala写的特殊库比一个用Java写的特殊哭更快。这并不真的意味着一个Java程序总是比一个Scala程序慢。
从Scala开始以来,我们就看到很多人好奇 是否Scala真的比Java慢.
基准测试得到了更多的关注, 这一个 是特殊的。它演示了一个用cpoll_cppsp 写的返回json的web程序比nodejs应用快4倍,后者每秒‘只’发送228,887次响应。
我写了一个实际的Web应用程序。我也贡献代码的Web框架。这和我有关吗?
不完全是。基准测试不会与实际应用有关系。同一个量级上,在一个节点上每秒228887次反应,比任何实际的应用数据都要多。
你可能会问为什么我花时间写我自己的基准测试?我期待着并希望能证明统一的API能比Java做的更好。与流行的观念相反,Scala程序可以比其对应的Java更快。
一个有趣的问题是:为什么“慢”的语言速度更快?答案其实很简单。一个更好的,可扩展的语言提供了更好的工具来写出更好的程序。
Java在微基准测试上打败Scala也不要紧。因为Java缺乏必要的构造,它强迫你使用的变通的方法,例如使用flect。这些方法不仅影响了你的程序的性能,更重要的是,他们是使得你的程序运行缓慢的原因。
关于正确复合和用户友好的一个案例Java的问题不友好的API
主要问题在于我使用了Java的validation API,(实际上与Java一样)不必要这么复杂。当然这个平凡的例子看起来漂亮的和简单的,但是当你开始钻研它后,事情就变得很有趣了:
让我们看一个简单的例子,跟踪JSR-303的一个实例:
24 | private List<Similar> similars; |
26 | private DateTime timestamp; |
28 | private String artist; |
30 | private List<Tag> tags; |
当然,这些看起来足够检查一个给定的跟踪实例是否是有效的了。
错了。你看,我们并没有明确的验证一个跟踪实例的有效性,还必须检查其Tags and Similars的有效性。你需要用@Valid标注每个属性。
这种行为是不合直觉的。当我不知道一个跟踪实例的成员是不是有效的时,我无法得它是否有效。
|