Scala 比 Java 还快?

jopen 7年前

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对象解析并且验证所花费的时间来测量。在两个不同的场景进行测试:

  • 所有对象都是有效的

  • 所有的对象有一个无效的字段

这是结果。较低的执行时间性能更好。

194516_nikx_95974.png

让人惊讶的是,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不仅简单而且高效的库称为可能。

你可以阅读 这篇文章 来了解更多关于unified API或者从这里检出代码.