Scala 比 Java 还快? 已翻译 100%

oschina 投递于 2014/06/22 21:58 (共 10 段, 翻译完成于 06-26)
阅读 26077
收藏 61
4
加载中

通常Scala被认为比Java要慢,特别是用于函数式编程时。本文会解释为什么这个被广泛接受的假设是错误的。

数据验证

编程中一个常见的问题是数据验证。即我们要确保所有得到的数据处于正确的结构中。我们需要从安全的,编译器验证的数据中找到不安全的外部输入。在一个典型的WEB应用中,你需要验证每个请求。很明显这会影响你的应用的性能。在本文中我将会比较处理这个问题的两种极不相同的解决方案。Java的Bean验证API和来自play的统一验证API。后者是一种更为函数式的方法,它具有不变性和类型安全的特性。

pseudo
pseudo
翻译于 2014/06/23 08:47
1

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);
pseudo
pseudo
翻译于 2014/06/23 08:58
1

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时,我没有太注重性能。我的主要目标是正确性,组合性和类型安全。实例上一些设计选择,例如惰性验证,都会对性能产生影响。接下来我们看下它是如何执行的。

pseudo
pseudo
翻译于 2014/06/23 09:13
1

基准

测试协议

该基准包括解析和验证存储在文件的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这边的影响不大。

AndyLam
AndyLam
翻译于 2014/06/25 19:51
1

基准测试不重要

那么我们学到了什么呢?

我们学到了在这特殊设置下,一个用Scala写的特殊库比一个用Java写的特殊库更快。这并不真的意味着一个Java程序总是比一个Scala程序慢。

从Scala开始以来,我们就看到很多人好奇 是否Scala真的比Java慢.

基准测试得到了更多的关注,  这一个 是特殊的。它演示了一个用cpoll_cppsp 写的返回json的web程序比nodejs应用快4倍,后者每秒‘只’发送228,887次响应。

麦壳原野
麦壳原野
翻译于 2014/06/23 10:17
1

我写了一个实际的Web应用程序。我也贡献代码的Web框架。这和我有关吗?

不完全是。基准测试不会与实际应用有关系。同一个量级上,在一个节点上每秒228887次反应,比任何实际的应用数据都要多。

你可能会问为什么我花时间写我自己的基准测试?我期待着并希望能证明统一的API能比Java做的更好。与流行的观念相反,Scala程序可以比其对应的Java更快。

一个有趣的问题是:为什么“慢”的语言速度更快?答案其实很简单。一个更好的,可扩展的语言提供了更好的工具来写出更好的程序。

Java在微基准测试上打败Scala也不要紧。因为Java缺乏必要的构造,它强迫你使用的变通的方法,例如使用flect。这些方法不仅影响了你的程序的性能,更重要的是,他们是使得你的程序运行缓慢的原因。

猪迪
猪迪
翻译于 2014/06/23 18:40
1

关于正确复合和用户友好的一个案例

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标注每个属性。

这种行为是不合直觉的。当我不知道一个跟踪实例的成员是不是有效的时,我无法得它是否有效。

猪迪
猪迪
翻译于 2014/06/23 19:02
1

校验与分解

JSR 303不处理数据的整理与分解。 他只是对类实例的校验。出于测试目的,我使用Jackson来将Json数据分解为类实例。但问题是,校验时分解的一部分。我们很难在没有检查JSon结构前提下将JSON树转化为类实例。 "age"属性存在吗?它是Integer类型的吗?

考虑到这点,Java 工作流看起来很奇怪。当处理Json时你实际上需要处理3中类型的错误:

  • Json数据不是结构良好的。

  • Json是有效的,但不是你想要的结构(例如,少了属性,类型不匹配等等)

  • 没有满足你定义的约束

JSR-303仅仅帮助你处理后者。

这个AIP同样强制你直接使用不合法的实例。我认为如果一个类实例不合法,你最初就不应该创建它。

麦壳原野
麦壳原野
翻译于 2014/06/24 09:59
1

难以扩展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中呢?好吧,我连写这些代码都不想写。这肯定会冗长并且乏味。

0x0bject
0x0bject
翻译于 2014/06/23 09:14
1

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或者从这里检出代码.

麦壳原野
麦壳原野
翻译于 2014/06/24 21:27
2
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(48)

jstat
jstat
scala 和 java 都是运行在JVM 上的字节码,所以要是scala 比java快。 要不就是java的代码写的比scala差,要不就是scala 有些语法特性在编译时得到了优化。相比前者后者才是应该拿出来讨论的。计算机语言特别是高级语言,比起效率更主要的目的是便于人思考更快速的写出计算机指令,要不然为什么会有c语言 汇编语言的效率难道不如c吗。
水山清风
水山清风
十分有趣的文章,作者在吐槽 java 做不出 scala 优美的验证 api,还有 java 做不出不需要运行时反射就可以把 json 映射成对象的功能.性能是附带的效果,一个全部依靠反射,一个全部不用反射,后者性能好一点是应该的,但这不是纠结的地方, play-json, circe 这些库甚至可以在编译的时候就已经知道这个对象可不可以序列化成 json 了,如果有字段类型不支持的话直接编译不通过,别说运行了, java 就不可以
Barudisshu
Barudisshu
毫无意义,主要还是看编译器的编译能力,这就是性能的瓶颈
火-星-人
火-星-人

引用来自“火-星-人”的评论

scala用java虚拟机运行还能比java快只能说明java写的烂

引用来自“首席生育师”的评论

SB
你叫SB?SB你好
开源中国-首席生育师
开源中国-首席生育师

引用来自“火-星-人”的评论

scala用java虚拟机运行还能比java快只能说明java写的烂
SB
qalong
qalong
这个文章真是太差劲了,没有任何价值的对比,一点也不公平。
java把json先对象化,然偶再验证;而scala是直接读取验证再序列化。只是编码规则不一样而已,所以速度肯定会有差别的。java的写法不仅仅是为了性能还有可读性,管理方便性。java写法还有要考虑json序列化的速度。
scala不错,但是不要不择手段的夸大鼓吹
捉鬼大帝
捉鬼大帝
无聊!!!!!!!
ylxs90
ylxs90

引用来自“萧猛”的评论

Scalac 和 javac 都是直接生成的是 JVM 字节码,相同功能的 scala代码和java代码如果在代码级别的优化都已经做到极致,那么运行时(使用同一版本的JVM)谁快就取决与 各自编译器生成字节码的质量。这样 scala 有可能 比java快,java也有可能比scala快,不同的代码段应该会有不同的结果,需要具体测试。
更大的差别在于Scala的编程方式与java有很大差别,函数式的编程方式容易写出并发性更好的代码,充分利用多核CPU. 其实java一样能写出并发性很好的代码,需要做更多的优化。
Scala 产生的大量小对象对内存的影响其实关系不大,因为虚拟机的内存回收是分代的(刚产生的对象属于新生代,经历多次回收还存在的对象属于旧生代)这些小对象会在新生代中被很快回收掉。
没啥可比性!java从四还是五开始!就完全专注于运行期优化了!为的就是让所有jvm语言都受益
mj4738
mj4738

引用来自“Narcissu5”的评论

这个与其说是java慢,不如说反射慢

另外scala生成的大量中间类毫无疑问会吃内存
我仔细看了两份示例代码,我也觉得这里不具可比性,
梁选
梁选

引用来自“leijiao”的评论

scala用java虚拟机运行还能比java快只能说明java写的烂

引用来自“南湖船老大”的评论

什么傻蛋逻辑啊。儿子就不能胜过老子,那社会怎么发展?

引用来自“leijiao”的评论

不是儿子跟老子的关系。多看看scala跟java关系再来评论。

引用来自“南湖船老大”的评论

当然知道,实际应该算兄弟关系。
当然,要看你怎么定义"快"
返回顶部
顶部