Scala 比 Java 还快?
Scala 比 Java 还快?
通常Scala被认为比Java要慢,特别是用于函数式编程时。本文会解释为什么这个被广泛接受的假设是错误的。
数据验证
编程中一个常见的问题是数据验证。即我们要确保所有得到的数据处于正确的结构中。我们需要从安全的,编译器验证的数据中找到不安全的外部输入。在一个典型的WEB应用中,你需要验证每个请求。很明显这会影响你的应用的性能。在本文中我将会比较处理这个问题的两种极不相同的解决方案。Java的Bean验证API和来自play的统一验证API。后者是一种更为函数式的方法,它具有不变性和类型安全的特性。
Java: Bean 验证API, aka JSR 303
Bean验证规范首发于2009年。此API使用注解为JavaBean设置约束。然后你需要在一个注解实例上调用验证方法来验证这个Bean的有效性。它的最著名的参考实现来自于Hibernate.
这是他们网址上的一个小示例。:
public class Car { @NotNull private String manufacturer; @NotNull @Size(min = 2, max = 14) private String licensePlate; @Min(2) private int seatCount; // ... }
这只是用于声明,真实的验证应该像这样(同样来自于他们的网址)。
ValidatorFactory factory = Validation.buildDefaultValidatorFactory(); Validator validator = factory.getValidator(); Car car = new Car("Ford", "0xCAFEBABE", 2); Set<ConstraintViolation<Car>> constraintViolations = validator.validate( car );
所以你将一个实例传递给validator.validate并获得一个包含错误的Set。如果这个Set是空的,那这个对象就是正确的。
通常你需要用此API来验证Json和XML.以下是一个解析和验证Json对象的例子。
public class Car { @NotNull private String manufacturer; @NotNull @Size(min = 2, max = 14) private String licensePlate; @Min(2) private int seatCount; // getters and setters } String json = ... // contains a json string representing a car ValidatorFactory factory = Validation.buildDefaultValidatorFactory(); Validator validator = factory.getValidator(); ObjectMapper mapper = new ObjectMapper(); Car car = mapper.readValue(json, Car.class); // use Jackson to unmarshall the json Set<ConstraintViolation<Car>> constraintViolations = validator.validate(car);
Scala: Play 统一验证 API.
这个统一验证API 致力于提供验证任何数据结构所需的核心原语。它的主要目的是替代Json验证API和play框架中的表单验证API。它易于拓展且支持Json验证和非传统的表单验证。
以下是一个Json验证场景的一点。注意这次我们在直接验证Json。
case class Car(manufacturer: String, licensePlate: String, seatCount: Int) val carValidation = From[JsValue]{ __ => ((__ \ "manufacturer").read[String] ~ (__ \ "seatCount").read(min(2)) ~ (__ \ "licensePlate").read(minLength(2) |+| maxLength(14)))(Car.apply _) } val json: String = ... // contains a json string representing a car val validationResult = From[JsObject, Car](json)
在实现此API时,我没有太注重性能。我的主要目标是正确性,组合性和类型安全。实例上一些设计选择,例如惰性验证,都会对性能产生影响。接下来我们看下它是如何执行的。
基准
测试协议
该基准包括解析和验证存储在文件的JSON对象. 这些数据是从 the Last.fm Dataset 抽取。JSON的结构已经被修改了一下,便于解析 (使用非常棒的 jq). 代码托管在 这里。
通过使用一系列的scala的计量基准测试进行性能测量. 这两个API都使用Jackson 解析JSON。
结果
基准用5000到10000的JSON对象解析并且验证所花费的时间来测量。在两个不同的场景进行测试:
所有对象都是有效的
所有的对象有一个无效的字段
这是结果。较低的执行时间性能更好。
让人惊讶的是,Scala的API快很多!
当对象有效时,Scala的API比Java API快1.6倍。
当对象包含一个无效的字段, Scala的API比Java API的速度更快,高达2.6倍Scala API is up 2.6x faster 。
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的一个实例:
public class Similar { @NotNull private String id; @Min(0) @Max(1) private float score; // .. getters and setters ... } public class Tag { @NotNull private String id; @NotNull private String score; // .. getters and setters ... } public class Track { @NotNull private String id; @NotNull private String title; @NotNull private List<Similar> similars; @NotNull private DateTime timestamp; @NotNull private String artist; @NotNull private List<Tag> tags; // .. getters and setters ... }
当然,这些看起来足够检查一个给定的跟踪实例是否是有效的了。
错了。你看,我们并没有明确的验证一个跟踪实例的有效性,还必须检查其Tags and Similars的有效性。你需要用@Valid标注每个属性。
这种行为是不合直觉的。当我不知道一个跟踪实例的成员是不是有效的时,我无法得它是否有效。
校验与分解
JSR 303不处理数据的整理与分解。 他只是对类实例的校验。出于测试目的,我使用Jackson来将Json数据分解为类实例。但问题是,校验时分解的一部分。我们很难在没有检查JSon结构前提下将JSON树转化为类实例。 "age"属性存在吗?它是Integer类型的吗?
考虑到这点,Java 工作流看起来很奇怪。当处理Json时你实际上需要处理3中类型的错误:
Json数据不是结构良好的。
Json是有效的,但不是你想要的结构(例如,少了属性,类型不匹配等等)
没有满足你定义的约束
JSR-303仅仅帮助你处理后者。
这个AIP同样强制你直接使用不合法的实例。我认为如果一个类实例不合法,你最初就不应该创建它。
难以扩展API
Hibernate校验程序需要手动添加一些列校验规则(如邮件,长度,非空等)。那如果你需要创建新的校验约束条件(比如从hibernate文档中的例子),你该怎么办?
@Target( { METHOD, FIELD, ANNOTATION_TYPE }) @Retention(RUNTIME) @Constraint(validatedBy = CheckCaseValidator.class) @Documented public @interface CheckCase { String message() default "{com.mycompany.constraints.checkcase}"; Class<?>[] groups() default {}; Class<? extends Payload>[] payload() default {}; CaseMode value(); } public class CheckCaseValidator implements ConstraintValidator<CheckCase, String> { private CaseMode caseMode; public void initialize(CheckCase constraintAnnotation) { this.caseMode = constraintAnnotation.value(); } public boolean isValid(String object, ConstraintValidatorContext constraintContext) { if (object == null) return true; if (caseMode == CaseMode.UPPER) return object.equals(object.toUpperCase()); else return object.equals(object.toLowerCase()); } }
那是大约 25 行代码。21 行基本上是固定的,所谓纯“仪式性”的。有趣的部分仅仅是:
if (caseMode == CaseMode.UPPER) return object.equals(object.toUpperCase()); else return object.equals(object.toLowerCase());
我们如何使用统一的校验API进行扩展相同的内容呢?
def checkCase(caseMode: CaseMode) = validateWith("constraints.checkcase") { (s: String) => if (caseMode == CaseMode.UPPER) s == s.toUpperCase else s == s.toLowerCase }
是的,这里只有6行代码。我有自信任何人都可以理解它。
现在,如果你有一个min规则,一个max规则,我想创建一个between规则,该怎么做?这很简单,规则组合。
def between(lower: Int, upper: Int) = min(lower) |+| max(upper)
然而在Java中呢?好吧,我连写这些代码都不想写。这肯定会冗长并且乏味。
Scala福利: 易于并行
作为一个小福利,既然Scala API只是用不可变的数据结构,那么它就是线程安全的。Scala 提供并行集合。让我们花5分钟改一些最初的代码,我提出了一个发挥我多核处理器最大性能的版本。
时间校验API测定Hibernate validator的基准点 - invalids Hibernate validator Unified - invalids Unified Unified w/ par - invalids Unified w/ par 5000 6000 7000 8000 9000 10000 0k 1k 2k 3k 4k 5k Highcharts.com
这一版本比Java的快了5倍。
结论
我认为这篇文章的观点相当明显。当提到选择一个库或者一门语言时,基准测试毫无用处。一个正确实现的算法总是能被优化。一个失败的实现就是失败了。
这一特殊的实例证明即使Scala有一些开销,但是它优秀的设计使得创建一些相比Java不仅简单而且高效的库称为可能。