从Graalvm性能测试结果看选择JVM和native-image的策略
从Graalvm性能测试结果看选择JVM和native-image的策略
- 测试环境
- 测试1
- 测试代码
- 测试结果
- 测试2
- 测试代码
- 测试结果
- 从测试结果分析JVM和native-image使用策率
GraalVM可以对Java应用进行二进制编译，从而生成可执行文件。按照GraalVM官方说法和一般的认知，编译后的可执行文件应该比虚拟机解释执行的Java运行更快。但是似乎情况也不都是如此，请看以下测试结果。
测试环境
测试环境如下，我使用以下4种Java虚拟机作为性能对比，同时还使用GravvlVM编译Java应用，对比可执行应用性能。
- RHEL 7.6 on BareMetal
- GravvlVM 19.2.1(基于OpenJDK 1.8.0_232 64bit)
- GravvlVM 19.3.0(基于OpenJDK 11.0.5 64bit)
- JDK Hotsport 1.8.0_232 64bit
- JDK Hotsport 13.0.1 64bit
- OpenJDK 13.0.1 64bit
测试1
测试代码
测试程序很简单，就是下面这段GraalVM官方提供的基于Java的测试代码。为了减少偶然性因素，我下面的测试代码将源代码的循环次数扩大了10倍。
public class CountUppercase {static final int ITERATIONS = Math.max(Integer.getInteger("iterations", 1), 1);public static void main(String[] args) {String sentence = String.join(" ", args);for (int iter = 0; iter < ITERATIONS; iter++) {if (ITERATIONS != 1) System.out.println("-- iteration " + (iter + 1) + " --");long total = 0, start = System.currentTimeMillis(), last = start;for (int i = 1; i < 100_000_000; i++) {total += sentence.chars().filter(Character::isUpperCase).count();if (i % 10_000_000 == 0) {long now = System.currentTimeMillis();System.out.printf("%d (%d ms)%n", i / 10_000_000, now - last);last = now;}}System.out.printf("total: %d (%d ms)%n", total, System.currentTimeMillis() - start);}}
}
测试结果
- 采用GravvlVM 19.2.1编译Java Class，然后采用GravvlVM 19.2.1、GravvlVM 19.3.0、JDK Hotspot 1.8.0_232、JDK Hotspot 13.0.1和OpenJDK13.0.1运行应用。执行参数为“In 2019 I would like to run ALL languages in one VM.”。每种JavaVM都记录5次测试结果（JDK Hotspot 1.8、JDK Hotspot 13和OpenJDK 13的测试结果有较大抖动，所以多测试了3组）。
- 采用GravvlVM 19.3.0编译Java Class，然后采用GravvlVM 19.3.0、JDK Hotspot 13.0.1和OpenJDK13.0.1运行应用。执行参数为“In 2019 I would like to run ALL languages in one VM.”。每种JavaVM都记录5次测试结果。
- 采用JDK Hotspot 1.8.0_232编译Java Class，然后采用GravvlVM 19.2.1、GravvlVM 19.3.0、JDK Hotspot 1.8.0_232、JDK Hotspot 13.0.1和OpenJDK13.0.1运行应用。执行参数为“In 2019 I would like to run ALL languages in one VM.”。每种JavaVM都记录5次测试结果（JDK Hotspot 1.8、JDK Hotspot 13和OpenJDK 13的测试结果有较大抖动，所以多测试了3组）。
- 采用JDK Hotspot 13.0.1编译Java Class，然后采用JDK Hotspot 13.0.1和OpenJDK13.0.1运行应用。执行参数为“In 2019 I would like to run ALL languages in one VM.”。每种JavaVM都记录8次测试结果。
- 采用GravvlVM 19.2.1编译Java Class，然后采用GravvlVM 19.2.1的nateve-image编译Java Class至可执行应用。然后测试可执行应用性能，执行参数为“In 2019 I would like to run ALL languages in one VM.”。
- 采用GravvlVM 19.3.0编译Java Class，然后采用GravvlVM 19.3.0的nateve-image编译Java Class至可执行应用。然后测试可执行应用性能，执行参数为“In 2019 I would like to run ALL languages in one VM.”。
测试2
测试代码
将代码中的循环减少到100次。然后在进行测试，本测试只GraalVM 19.3.0的native-image和JDK Hotspot 13.0.1的执行的执行时间。
public class CountUppercase {static final int ITERATIONS = Math.max(Integer.getInteger("iterations", 1), 1);public static void main(String[] args) {String sentence = String.join(" ", args);for (int iter = 0; iter < ITERATIONS; iter++) {if (ITERATIONS != 1) System.out.println("-- iteration " + (iter + 1) + " --");long total = 0, start = System.currentTimeMillis(), last = start;for (int i = 1; i < 100; i++) {total += sentence.chars().filter(Character::isUpperCase).count();if (i % 10 == 0) {long now = System.currentTimeMillis();System.out.printf("%d (%d ms)%n", i / 10, now - last);last = now;}}System.out.printf("total: %d (%d ms)%n", total, System.currentTimeMillis() - start);}}
}
测试结果
可以看到可执行文件的执行速度要比Java Class执行的要快很多。
$ time countuppercase In 2019 I would like to run ALL languages in one VM.
1 (0 ms)
2 (0 ms)
3 (0 ms)
4 (0 ms)
5 (0 ms)
6 (0 ms)
7 (1 ms)
8 (0 ms)
9 (0 ms)
total: 693 (1 ms)real 0m0.003s
user 0m0.000s
sys 0m0.003s$ time ~/graalvm/bin/java CountUppercase In 2019 I would like to run ALL languages in one VM.
1 (4 ms)
2 (23 ms)
3 (0 ms)
4 (1 ms)
5 (0 ms)
6 (1 ms)
7 (0 ms)
8 (1 ms)
9 (0 ms)
total: 693 (31 ms)real 0m0.143s
user 0m0.182s
sys 0m0.053s从测试结果分析JVM和native-image使用策率
- 不管是否是通过GraalVM编译的Java Class，GraalVM运行这些Java应用都要比Oracle的Hotspot以及开原的OpenJDK快，而且优势较为明显。
- 不清楚为什么非GraalVM的运行结果都有明显抖动，用时差能有50%甚至还多，抖动比较明显。用同版本JDK编译后再运行，测试抖动情况少了一些，但是没有彻底根除。我已经排除了JVM垃圾回收的因素，但还找不到原因。至少经验是如果是Hotspot或OpenJDK，编译用是什么版本，运行就用什么版本。
- 虽然GraalVM19.3.0比GraalVM19.2.1的native-image的编译和执行速度快些。
- 经GraalVM的native-image编译后可执行文件并非在任何场景都比Java Class快。前者的主要优势在于超快的启动速度（这一优势尤其适合结合Container实现基于事件的响应处理、Serverless架构等，从而有很好的响应速度和弹性扩展速度），而大量的循环处理反而倒是后者快（还没想明白为什么可执行应用的循环会慢）。至于到底该不该用native-image将Java Class编译成二进制可执行应用？最好还是测试一下！！！
从Graalvm性能测试结果看选择JVM和native-image的策略相关推荐
- 性能测试培训：定位jvm耗时函数
性能测试培训:定位jvm耗时函数 poptest是国内唯一一家培养测试开发工程师的培训机构,以学员能胜任自动化测试,性能测试,测试工具开发等工作为目标.如果对课程感兴趣,请大家咨询qq:9088214 ...
- 电脑核显可以用html吗,GPU性能测试：看最强核显能干翻哪些独显
●评测平台及方法说明 本次评测主要从CPU.GPU性能及功耗三方面进行,在CPU性能评测中除了加入4790K.6700K,同时增加三款CPU同频率对比作为辅助参考:而在GPU性能评测中,我们将加入AP ...
- 深入理解Java虚拟机（第三弹）- JVM 内存分配与回收策略原理，从此告别 JVM 内存分配文盲
点击上方 好好学java ,选择 星标 公众号 重磅资讯.干货,第一时间送达 今日推荐:打卡活动第二期来啦,100% 能获得奖品个人原创+1博客:点击前往,查看更多 虚拟机系列文章 深入理解 Java ...
- 【拥抱大厂系列】百度面试官问过的 “JVM内存分配与回收策略原理”，我用这篇文章搞定了
点个赞,看一看,好习惯!本文 GitHub https://github.com/OUYANGSIHAI/JavaInterview 已收录,这是我花了3个月总结的一线大厂Java面试总结,本人已拿腾 ...
- JAVA之JVM分代垃圾回收策略（一）
一.为什么要分代 分代的垃圾回收策略,是基于这样一个事实:不同的对象的生命周期是不一样的.因此,不同生命周期的对象可以采取不同的收集方式,以便提高回收效率. 在Java程序运行的过程中,会产生大量的对 ...
- JVM内存模型及垃圾收集策略解析(一)
http://www.cnblogs.com/laoyangHJ/archive/2011/08/17/jvm_model.html JVM内存模型是Java的核心技术之一,之前51CTO曾为大家介绍 ...
- JVM分代垃圾回收策略的基础概念
JVM分代垃圾回收策略的基础概念 由于不同对象的生命周期不一样,因此在JVM的垃圾回收策略中有分代这一策略.本文介绍了分代策略的目标,如何分代,以及垃圾回收的触发因素. 文章总结了JVM垃圾回收策略为 ...
- 一文看尽 JVM GC 调优
一个著名的学习方法论 向橡皮鸭求助 学会提问,提问也是一门艺术 提问前,先投入自己的时间做好功课 发生了什么事情 问题的基本情况 你投入的研究和发现 能正确提出你的问题,你的问题差不多已经解决一半 深 ...
- java性能调试命令_性能测试必备监控技能jvm之jdk命令行工具篇16
3.png 前言 对于JVM的性能监控,主要注意以下关键参数,通过jdk自带的命令行工具,即可查看相关参数,从而分析系统或目标服务程序中存在的性能瓶颈 jps JVM Process Status T ...
最新文章
- LabVIEW图像增强算法（基础篇—5）
- 网络编程学习笔记(recvmsg和sendmsg函数)
- python获取系统硬件信息
- VS扩展CodeMaid代码整理插件
- 牛顿儿时成绩很差，5岁开始接触物理，也许是他如此伟大的唯一原因！
- 多益网络 视频面试面试总结20180816
- 变形 圆形_中山125T圆形玻璃钢冷却塔现场安装
- 机器学习入门05 - 泛化 (Generalization)
- 黑客帝国屏保源码！快拿去试试吧！炫酷无比！
- 使用QUARKUS开发JSON REST 服务
- Android性能专项FPS测试实践
- 微信登录（官方指导）
- 解读德国政府未来可能采用的加密即时通讯框架
- android休闲游戏,休闲放松是王道 六款安卓休闲游戏推荐
- 我参加NVIDIA Sky Hackathon 训练文件的路径设置
- 【依葫芦画瓢】SSM-CRUD --- 2
- 基于Springboot + Vue2.0开发的 IM 在线聊天
- 电子表格软件能解决什么问题?
- telnet远程管理及AAA认证方式
- Dialog的Dismiss方法使用注意事项