ODIn/spark-instrumented-optimizer
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
spark-instrumented-optimizer/core/benchmarks/PropertiesCloneBenchmark-results.txt

41 lines
3.1 KiB
Plaintext
Raw Normal View History

[SPARK-29081][CORE] Replace calls to SerializationUtils.clone on properties with a faster implementation Replace use of `SerializationUtils.clone` with new `Utils.cloneProperties` method Add benchmark + results showing dramatic speed up for effectively equivalent functionality. ### What changes were proposed in this pull request? While I am not sure that SerializationUtils.clone is a performance issue in production, I am sure that it is overkill for the task it is doing (providing a distinct copy of a `Properties` object). This PR provides a benchmark showing the dramatic improvement over the clone operation and replaces uses of `SerializationUtils.clone` on `Properties` with the more specialized `Utils.cloneProperties`. ### Does this PR introduce any user-facing change? Strings are immutable so there is no reason to serialize and deserialize them, it just creates extra garbage. The only functionality that would be changed is the unsupported insertion of non-String objects into the spark local properties. ### How was this patch tested? 1. Pass the Jenkins with the existing tests. 2. Since this is a performance improvement PR, manually run the benchmark. Closes #25787 from databricks-david-lewis/SPARK-29081. Authored-by: David Lewis <david.lewis@databricks.com> Signed-off-by: Dongjoon Hyun <dhyun@apple.com>
2019-09-15 03:28:32 -04:00
================================================================================================
Properties Cloning
================================================================================================
[SPARK-34950][TESTS] Update benchmark results to the ones created by GitHub Actions machines ### What changes were proposed in this pull request? https://github.com/apache/spark/pull/32015 added a way to run benchmarks much more easily in the same GitHub Actions build. This PR updates the benchmark results by using the way. **NOTE** that looks like GitHub Actions use four types of CPU given my observations: - Intel(R) Xeon(R) Platinum 8171M CPU 2.60GHz - Intel(R) Xeon(R) CPU E5-2673 v4 2.30GHz - Intel(R) Xeon(R) CPU E5-2673 v3 2.40GHz - Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz Given my quick research, seems like they perform roughly similarly: ![Screen Shot 2021-04-03 at 9 31 23 PM](https://user-images.githubusercontent.com/6477701/113478478-f4b57b80-94c3-11eb-9047-f81ca8c59672.png) I couldn't find enough information about Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz but the performance seems roughly similar given the numbers. So shouldn't be a big deal especially given that this way is much easier, encourages contributors to run more and guarantee the same number of cores and same memory with the same softwares. ### Why are the changes needed? To have a base line of the benchmarks accordingly. ### Does this PR introduce _any_ user-facing change? No, dev-only. ### How was this patch tested? It was generated from: - [Run benchmarks: * (JDK 11)](https://github.com/HyukjinKwon/spark/actions/runs/713575465) - [Run benchmarks: * (JDK 8)](https://github.com/HyukjinKwon/spark/actions/runs/713154337) Closes #32044 from HyukjinKwon/SPARK-34950. Authored-by: HyukjinKwon <gurwls223@apache.org> Signed-off-by: Max Gekk <max.gekk@gmail.com>
2021-04-03 16:02:56 -04:00
OpenJDK 64-Bit Server VM 1.8.0_282-b08 on Linux 5.4.0-1043-azure
Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
[SPARK-29081][CORE] Replace calls to SerializationUtils.clone on properties with a faster implementation Replace use of `SerializationUtils.clone` with new `Utils.cloneProperties` method Add benchmark + results showing dramatic speed up for effectively equivalent functionality. ### What changes were proposed in this pull request? While I am not sure that SerializationUtils.clone is a performance issue in production, I am sure that it is overkill for the task it is doing (providing a distinct copy of a `Properties` object). This PR provides a benchmark showing the dramatic improvement over the clone operation and replaces uses of `SerializationUtils.clone` on `Properties` with the more specialized `Utils.cloneProperties`. ### Does this PR introduce any user-facing change? Strings are immutable so there is no reason to serialize and deserialize them, it just creates extra garbage. The only functionality that would be changed is the unsupported insertion of non-String objects into the spark local properties. ### How was this patch tested? 1. Pass the Jenkins with the existing tests. 2. Since this is a performance improvement PR, manually run the benchmark. Closes #25787 from databricks-david-lewis/SPARK-29081. Authored-by: David Lewis <david.lewis@databricks.com> Signed-off-by: Dongjoon Hyun <dhyun@apple.com>
2019-09-15 03:28:32 -04:00
Empty Properties: Best Time(ms) Avg Time(ms) Stdev(ms) Rate(M/s) Per Row(ns) Relative
------------------------------------------------------------------------------------------------------------------------
[SPARK-34950][TESTS] Update benchmark results to the ones created by GitHub Actions machines ### What changes were proposed in this pull request? https://github.com/apache/spark/pull/32015 added a way to run benchmarks much more easily in the same GitHub Actions build. This PR updates the benchmark results by using the way. **NOTE** that looks like GitHub Actions use four types of CPU given my observations: - Intel(R) Xeon(R) Platinum 8171M CPU 2.60GHz - Intel(R) Xeon(R) CPU E5-2673 v4 2.30GHz - Intel(R) Xeon(R) CPU E5-2673 v3 2.40GHz - Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz Given my quick research, seems like they perform roughly similarly: ![Screen Shot 2021-04-03 at 9 31 23 PM](https://user-images.githubusercontent.com/6477701/113478478-f4b57b80-94c3-11eb-9047-f81ca8c59672.png) I couldn't find enough information about Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz but the performance seems roughly similar given the numbers. So shouldn't be a big deal especially given that this way is much easier, encourages contributors to run more and guarantee the same number of cores and same memory with the same softwares. ### Why are the changes needed? To have a base line of the benchmarks accordingly. ### Does this PR introduce _any_ user-facing change? No, dev-only. ### How was this patch tested? It was generated from: - [Run benchmarks: * (JDK 11)](https://github.com/HyukjinKwon/spark/actions/runs/713575465) - [Run benchmarks: * (JDK 8)](https://github.com/HyukjinKwon/spark/actions/runs/713154337) Closes #32044 from HyukjinKwon/SPARK-34950. Authored-by: HyukjinKwon <gurwls223@apache.org> Signed-off-by: Max Gekk <max.gekk@gmail.com>
2021-04-03 16:02:56 -04:00
SerializationUtils.clone 0 0 0 0.2 5599.0 1.0X
Utils.cloneProperties 0 0 0 Infinity 0.0 InfinityX
[SPARK-29081][CORE] Replace calls to SerializationUtils.clone on properties with a faster implementation Replace use of `SerializationUtils.clone` with new `Utils.cloneProperties` method Add benchmark + results showing dramatic speed up for effectively equivalent functionality. ### What changes were proposed in this pull request? While I am not sure that SerializationUtils.clone is a performance issue in production, I am sure that it is overkill for the task it is doing (providing a distinct copy of a `Properties` object). This PR provides a benchmark showing the dramatic improvement over the clone operation and replaces uses of `SerializationUtils.clone` on `Properties` with the more specialized `Utils.cloneProperties`. ### Does this PR introduce any user-facing change? Strings are immutable so there is no reason to serialize and deserialize them, it just creates extra garbage. The only functionality that would be changed is the unsupported insertion of non-String objects into the spark local properties. ### How was this patch tested? 1. Pass the Jenkins with the existing tests. 2. Since this is a performance improvement PR, manually run the benchmark. Closes #25787 from databricks-david-lewis/SPARK-29081. Authored-by: David Lewis <david.lewis@databricks.com> Signed-off-by: Dongjoon Hyun <dhyun@apple.com>
2019-09-15 03:28:32 -04:00
[SPARK-34950][TESTS] Update benchmark results to the ones created by GitHub Actions machines ### What changes were proposed in this pull request? https://github.com/apache/spark/pull/32015 added a way to run benchmarks much more easily in the same GitHub Actions build. This PR updates the benchmark results by using the way. **NOTE** that looks like GitHub Actions use four types of CPU given my observations: - Intel(R) Xeon(R) Platinum 8171M CPU 2.60GHz - Intel(R) Xeon(R) CPU E5-2673 v4 2.30GHz - Intel(R) Xeon(R) CPU E5-2673 v3 2.40GHz - Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz Given my quick research, seems like they perform roughly similarly: ![Screen Shot 2021-04-03 at 9 31 23 PM](https://user-images.githubusercontent.com/6477701/113478478-f4b57b80-94c3-11eb-9047-f81ca8c59672.png) I couldn't find enough information about Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz but the performance seems roughly similar given the numbers. So shouldn't be a big deal especially given that this way is much easier, encourages contributors to run more and guarantee the same number of cores and same memory with the same softwares. ### Why are the changes needed? To have a base line of the benchmarks accordingly. ### Does this PR introduce _any_ user-facing change? No, dev-only. ### How was this patch tested? It was generated from: - [Run benchmarks: * (JDK 11)](https://github.com/HyukjinKwon/spark/actions/runs/713575465) - [Run benchmarks: * (JDK 8)](https://github.com/HyukjinKwon/spark/actions/runs/713154337) Closes #32044 from HyukjinKwon/SPARK-34950. Authored-by: HyukjinKwon <gurwls223@apache.org> Signed-off-by: Max Gekk <max.gekk@gmail.com>
2021-04-03 16:02:56 -04:00
OpenJDK 64-Bit Server VM 1.8.0_282-b08 on Linux 5.4.0-1043-azure
Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
[SPARK-29081][CORE] Replace calls to SerializationUtils.clone on properties with a faster implementation Replace use of `SerializationUtils.clone` with new `Utils.cloneProperties` method Add benchmark + results showing dramatic speed up for effectively equivalent functionality. ### What changes were proposed in this pull request? While I am not sure that SerializationUtils.clone is a performance issue in production, I am sure that it is overkill for the task it is doing (providing a distinct copy of a `Properties` object). This PR provides a benchmark showing the dramatic improvement over the clone operation and replaces uses of `SerializationUtils.clone` on `Properties` with the more specialized `Utils.cloneProperties`. ### Does this PR introduce any user-facing change? Strings are immutable so there is no reason to serialize and deserialize them, it just creates extra garbage. The only functionality that would be changed is the unsupported insertion of non-String objects into the spark local properties. ### How was this patch tested? 1. Pass the Jenkins with the existing tests. 2. Since this is a performance improvement PR, manually run the benchmark. Closes #25787 from databricks-david-lewis/SPARK-29081. Authored-by: David Lewis <david.lewis@databricks.com> Signed-off-by: Dongjoon Hyun <dhyun@apple.com>
2019-09-15 03:28:32 -04:00
System Properties: Best Time(ms) Avg Time(ms) Stdev(ms) Rate(M/s) Per Row(ns) Relative
------------------------------------------------------------------------------------------------------------------------
[SPARK-34950][TESTS] Update benchmark results to the ones created by GitHub Actions machines ### What changes were proposed in this pull request? https://github.com/apache/spark/pull/32015 added a way to run benchmarks much more easily in the same GitHub Actions build. This PR updates the benchmark results by using the way. **NOTE** that looks like GitHub Actions use four types of CPU given my observations: - Intel(R) Xeon(R) Platinum 8171M CPU 2.60GHz - Intel(R) Xeon(R) CPU E5-2673 v4 2.30GHz - Intel(R) Xeon(R) CPU E5-2673 v3 2.40GHz - Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz Given my quick research, seems like they perform roughly similarly: ![Screen Shot 2021-04-03 at 9 31 23 PM](https://user-images.githubusercontent.com/6477701/113478478-f4b57b80-94c3-11eb-9047-f81ca8c59672.png) I couldn't find enough information about Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz but the performance seems roughly similar given the numbers. So shouldn't be a big deal especially given that this way is much easier, encourages contributors to run more and guarantee the same number of cores and same memory with the same softwares. ### Why are the changes needed? To have a base line of the benchmarks accordingly. ### Does this PR introduce _any_ user-facing change? No, dev-only. ### How was this patch tested? It was generated from: - [Run benchmarks: * (JDK 11)](https://github.com/HyukjinKwon/spark/actions/runs/713575465) - [Run benchmarks: * (JDK 8)](https://github.com/HyukjinKwon/spark/actions/runs/713154337) Closes #32044 from HyukjinKwon/SPARK-34950. Authored-by: HyukjinKwon <gurwls223@apache.org> Signed-off-by: Max Gekk <max.gekk@gmail.com>
2021-04-03 16:02:56 -04:00
SerializationUtils.clone 0 0 0 0.0 339506.0 1.0X
Utils.cloneProperties 0 0 0 0.5 1900.0 178.7X
[SPARK-29081][CORE] Replace calls to SerializationUtils.clone on properties with a faster implementation Replace use of `SerializationUtils.clone` with new `Utils.cloneProperties` method Add benchmark + results showing dramatic speed up for effectively equivalent functionality. ### What changes were proposed in this pull request? While I am not sure that SerializationUtils.clone is a performance issue in production, I am sure that it is overkill for the task it is doing (providing a distinct copy of a `Properties` object). This PR provides a benchmark showing the dramatic improvement over the clone operation and replaces uses of `SerializationUtils.clone` on `Properties` with the more specialized `Utils.cloneProperties`. ### Does this PR introduce any user-facing change? Strings are immutable so there is no reason to serialize and deserialize them, it just creates extra garbage. The only functionality that would be changed is the unsupported insertion of non-String objects into the spark local properties. ### How was this patch tested? 1. Pass the Jenkins with the existing tests. 2. Since this is a performance improvement PR, manually run the benchmark. Closes #25787 from databricks-david-lewis/SPARK-29081. Authored-by: David Lewis <david.lewis@databricks.com> Signed-off-by: Dongjoon Hyun <dhyun@apple.com>
2019-09-15 03:28:32 -04:00
[SPARK-34950][TESTS] Update benchmark results to the ones created by GitHub Actions machines ### What changes were proposed in this pull request? https://github.com/apache/spark/pull/32015 added a way to run benchmarks much more easily in the same GitHub Actions build. This PR updates the benchmark results by using the way. **NOTE** that looks like GitHub Actions use four types of CPU given my observations: - Intel(R) Xeon(R) Platinum 8171M CPU 2.60GHz - Intel(R) Xeon(R) CPU E5-2673 v4 2.30GHz - Intel(R) Xeon(R) CPU E5-2673 v3 2.40GHz - Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz Given my quick research, seems like they perform roughly similarly: ![Screen Shot 2021-04-03 at 9 31 23 PM](https://user-images.githubusercontent.com/6477701/113478478-f4b57b80-94c3-11eb-9047-f81ca8c59672.png) I couldn't find enough information about Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz but the performance seems roughly similar given the numbers. So shouldn't be a big deal especially given that this way is much easier, encourages contributors to run more and guarantee the same number of cores and same memory with the same softwares. ### Why are the changes needed? To have a base line of the benchmarks accordingly. ### Does this PR introduce _any_ user-facing change? No, dev-only. ### How was this patch tested? It was generated from: - [Run benchmarks: * (JDK 11)](https://github.com/HyukjinKwon/spark/actions/runs/713575465) - [Run benchmarks: * (JDK 8)](https://github.com/HyukjinKwon/spark/actions/runs/713154337) Closes #32044 from HyukjinKwon/SPARK-34950. Authored-by: HyukjinKwon <gurwls223@apache.org> Signed-off-by: Max Gekk <max.gekk@gmail.com>
2021-04-03 16:02:56 -04:00
OpenJDK 64-Bit Server VM 1.8.0_282-b08 on Linux 5.4.0-1043-azure
Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
[SPARK-29081][CORE] Replace calls to SerializationUtils.clone on properties with a faster implementation Replace use of `SerializationUtils.clone` with new `Utils.cloneProperties` method Add benchmark + results showing dramatic speed up for effectively equivalent functionality. ### What changes were proposed in this pull request? While I am not sure that SerializationUtils.clone is a performance issue in production, I am sure that it is overkill for the task it is doing (providing a distinct copy of a `Properties` object). This PR provides a benchmark showing the dramatic improvement over the clone operation and replaces uses of `SerializationUtils.clone` on `Properties` with the more specialized `Utils.cloneProperties`. ### Does this PR introduce any user-facing change? Strings are immutable so there is no reason to serialize and deserialize them, it just creates extra garbage. The only functionality that would be changed is the unsupported insertion of non-String objects into the spark local properties. ### How was this patch tested? 1. Pass the Jenkins with the existing tests. 2. Since this is a performance improvement PR, manually run the benchmark. Closes #25787 from databricks-david-lewis/SPARK-29081. Authored-by: David Lewis <david.lewis@databricks.com> Signed-off-by: Dongjoon Hyun <dhyun@apple.com>
2019-09-15 03:28:32 -04:00
Small Properties: Best Time(ms) Avg Time(ms) Stdev(ms) Rate(M/s) Per Row(ns) Relative
------------------------------------------------------------------------------------------------------------------------
[SPARK-34950][TESTS] Update benchmark results to the ones created by GitHub Actions machines ### What changes were proposed in this pull request? https://github.com/apache/spark/pull/32015 added a way to run benchmarks much more easily in the same GitHub Actions build. This PR updates the benchmark results by using the way. **NOTE** that looks like GitHub Actions use four types of CPU given my observations: - Intel(R) Xeon(R) Platinum 8171M CPU 2.60GHz - Intel(R) Xeon(R) CPU E5-2673 v4 2.30GHz - Intel(R) Xeon(R) CPU E5-2673 v3 2.40GHz - Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz Given my quick research, seems like they perform roughly similarly: ![Screen Shot 2021-04-03 at 9 31 23 PM](https://user-images.githubusercontent.com/6477701/113478478-f4b57b80-94c3-11eb-9047-f81ca8c59672.png) I couldn't find enough information about Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz but the performance seems roughly similar given the numbers. So shouldn't be a big deal especially given that this way is much easier, encourages contributors to run more and guarantee the same number of cores and same memory with the same softwares. ### Why are the changes needed? To have a base line of the benchmarks accordingly. ### Does this PR introduce _any_ user-facing change? No, dev-only. ### How was this patch tested? It was generated from: - [Run benchmarks: * (JDK 11)](https://github.com/HyukjinKwon/spark/actions/runs/713575465) - [Run benchmarks: * (JDK 8)](https://github.com/HyukjinKwon/spark/actions/runs/713154337) Closes #32044 from HyukjinKwon/SPARK-34950. Authored-by: HyukjinKwon <gurwls223@apache.org> Signed-off-by: Max Gekk <max.gekk@gmail.com>
2021-04-03 16:02:56 -04:00
SerializationUtils.clone 1 1 0 0.0 604411.0 1.0X
Utils.cloneProperties 0 0 0 0.2 5100.0 118.5X
[SPARK-29081][CORE] Replace calls to SerializationUtils.clone on properties with a faster implementation Replace use of `SerializationUtils.clone` with new `Utils.cloneProperties` method Add benchmark + results showing dramatic speed up for effectively equivalent functionality. ### What changes were proposed in this pull request? While I am not sure that SerializationUtils.clone is a performance issue in production, I am sure that it is overkill for the task it is doing (providing a distinct copy of a `Properties` object). This PR provides a benchmark showing the dramatic improvement over the clone operation and replaces uses of `SerializationUtils.clone` on `Properties` with the more specialized `Utils.cloneProperties`. ### Does this PR introduce any user-facing change? Strings are immutable so there is no reason to serialize and deserialize them, it just creates extra garbage. The only functionality that would be changed is the unsupported insertion of non-String objects into the spark local properties. ### How was this patch tested? 1. Pass the Jenkins with the existing tests. 2. Since this is a performance improvement PR, manually run the benchmark. Closes #25787 from databricks-david-lewis/SPARK-29081. Authored-by: David Lewis <david.lewis@databricks.com> Signed-off-by: Dongjoon Hyun <dhyun@apple.com>
2019-09-15 03:28:32 -04:00
[SPARK-34950][TESTS] Update benchmark results to the ones created by GitHub Actions machines ### What changes were proposed in this pull request? https://github.com/apache/spark/pull/32015 added a way to run benchmarks much more easily in the same GitHub Actions build. This PR updates the benchmark results by using the way. **NOTE** that looks like GitHub Actions use four types of CPU given my observations: - Intel(R) Xeon(R) Platinum 8171M CPU 2.60GHz - Intel(R) Xeon(R) CPU E5-2673 v4 2.30GHz - Intel(R) Xeon(R) CPU E5-2673 v3 2.40GHz - Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz Given my quick research, seems like they perform roughly similarly: ![Screen Shot 2021-04-03 at 9 31 23 PM](https://user-images.githubusercontent.com/6477701/113478478-f4b57b80-94c3-11eb-9047-f81ca8c59672.png) I couldn't find enough information about Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz but the performance seems roughly similar given the numbers. So shouldn't be a big deal especially given that this way is much easier, encourages contributors to run more and guarantee the same number of cores and same memory with the same softwares. ### Why are the changes needed? To have a base line of the benchmarks accordingly. ### Does this PR introduce _any_ user-facing change? No, dev-only. ### How was this patch tested? It was generated from: - [Run benchmarks: * (JDK 11)](https://github.com/HyukjinKwon/spark/actions/runs/713575465) - [Run benchmarks: * (JDK 8)](https://github.com/HyukjinKwon/spark/actions/runs/713154337) Closes #32044 from HyukjinKwon/SPARK-34950. Authored-by: HyukjinKwon <gurwls223@apache.org> Signed-off-by: Max Gekk <max.gekk@gmail.com>
2021-04-03 16:02:56 -04:00
OpenJDK 64-Bit Server VM 1.8.0_282-b08 on Linux 5.4.0-1043-azure
Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
[SPARK-29081][CORE] Replace calls to SerializationUtils.clone on properties with a faster implementation Replace use of `SerializationUtils.clone` with new `Utils.cloneProperties` method Add benchmark + results showing dramatic speed up for effectively equivalent functionality. ### What changes were proposed in this pull request? While I am not sure that SerializationUtils.clone is a performance issue in production, I am sure that it is overkill for the task it is doing (providing a distinct copy of a `Properties` object). This PR provides a benchmark showing the dramatic improvement over the clone operation and replaces uses of `SerializationUtils.clone` on `Properties` with the more specialized `Utils.cloneProperties`. ### Does this PR introduce any user-facing change? Strings are immutable so there is no reason to serialize and deserialize them, it just creates extra garbage. The only functionality that would be changed is the unsupported insertion of non-String objects into the spark local properties. ### How was this patch tested? 1. Pass the Jenkins with the existing tests. 2. Since this is a performance improvement PR, manually run the benchmark. Closes #25787 from databricks-david-lewis/SPARK-29081. Authored-by: David Lewis <david.lewis@databricks.com> Signed-off-by: Dongjoon Hyun <dhyun@apple.com>
2019-09-15 03:28:32 -04:00
Medium Properties: Best Time(ms) Avg Time(ms) Stdev(ms) Rate(M/s) Per Row(ns) Relative
------------------------------------------------------------------------------------------------------------------------
[SPARK-34950][TESTS] Update benchmark results to the ones created by GitHub Actions machines ### What changes were proposed in this pull request? https://github.com/apache/spark/pull/32015 added a way to run benchmarks much more easily in the same GitHub Actions build. This PR updates the benchmark results by using the way. **NOTE** that looks like GitHub Actions use four types of CPU given my observations: - Intel(R) Xeon(R) Platinum 8171M CPU 2.60GHz - Intel(R) Xeon(R) CPU E5-2673 v4 2.30GHz - Intel(R) Xeon(R) CPU E5-2673 v3 2.40GHz - Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz Given my quick research, seems like they perform roughly similarly: ![Screen Shot 2021-04-03 at 9 31 23 PM](https://user-images.githubusercontent.com/6477701/113478478-f4b57b80-94c3-11eb-9047-f81ca8c59672.png) I couldn't find enough information about Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz but the performance seems roughly similar given the numbers. So shouldn't be a big deal especially given that this way is much easier, encourages contributors to run more and guarantee the same number of cores and same memory with the same softwares. ### Why are the changes needed? To have a base line of the benchmarks accordingly. ### Does this PR introduce _any_ user-facing change? No, dev-only. ### How was this patch tested? It was generated from: - [Run benchmarks: * (JDK 11)](https://github.com/HyukjinKwon/spark/actions/runs/713575465) - [Run benchmarks: * (JDK 8)](https://github.com/HyukjinKwon/spark/actions/runs/713154337) Closes #32044 from HyukjinKwon/SPARK-34950. Authored-by: HyukjinKwon <gurwls223@apache.org> Signed-off-by: Max Gekk <max.gekk@gmail.com>
2021-04-03 16:02:56 -04:00
SerializationUtils.clone 2 2 0 0.0 2378345.0 1.0X
Utils.cloneProperties 0 0 0 0.0 25100.0 94.8X
[SPARK-29081][CORE] Replace calls to SerializationUtils.clone on properties with a faster implementation Replace use of `SerializationUtils.clone` with new `Utils.cloneProperties` method Add benchmark + results showing dramatic speed up for effectively equivalent functionality. ### What changes were proposed in this pull request? While I am not sure that SerializationUtils.clone is a performance issue in production, I am sure that it is overkill for the task it is doing (providing a distinct copy of a `Properties` object). This PR provides a benchmark showing the dramatic improvement over the clone operation and replaces uses of `SerializationUtils.clone` on `Properties` with the more specialized `Utils.cloneProperties`. ### Does this PR introduce any user-facing change? Strings are immutable so there is no reason to serialize and deserialize them, it just creates extra garbage. The only functionality that would be changed is the unsupported insertion of non-String objects into the spark local properties. ### How was this patch tested? 1. Pass the Jenkins with the existing tests. 2. Since this is a performance improvement PR, manually run the benchmark. Closes #25787 from databricks-david-lewis/SPARK-29081. Authored-by: David Lewis <david.lewis@databricks.com> Signed-off-by: Dongjoon Hyun <dhyun@apple.com>
2019-09-15 03:28:32 -04:00
[SPARK-34950][TESTS] Update benchmark results to the ones created by GitHub Actions machines ### What changes were proposed in this pull request? https://github.com/apache/spark/pull/32015 added a way to run benchmarks much more easily in the same GitHub Actions build. This PR updates the benchmark results by using the way. **NOTE** that looks like GitHub Actions use four types of CPU given my observations: - Intel(R) Xeon(R) Platinum 8171M CPU 2.60GHz - Intel(R) Xeon(R) CPU E5-2673 v4 2.30GHz - Intel(R) Xeon(R) CPU E5-2673 v3 2.40GHz - Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz Given my quick research, seems like they perform roughly similarly: ![Screen Shot 2021-04-03 at 9 31 23 PM](https://user-images.githubusercontent.com/6477701/113478478-f4b57b80-94c3-11eb-9047-f81ca8c59672.png) I couldn't find enough information about Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz but the performance seems roughly similar given the numbers. So shouldn't be a big deal especially given that this way is much easier, encourages contributors to run more and guarantee the same number of cores and same memory with the same softwares. ### Why are the changes needed? To have a base line of the benchmarks accordingly. ### Does this PR introduce _any_ user-facing change? No, dev-only. ### How was this patch tested? It was generated from: - [Run benchmarks: * (JDK 11)](https://github.com/HyukjinKwon/spark/actions/runs/713575465) - [Run benchmarks: * (JDK 8)](https://github.com/HyukjinKwon/spark/actions/runs/713154337) Closes #32044 from HyukjinKwon/SPARK-34950. Authored-by: HyukjinKwon <gurwls223@apache.org> Signed-off-by: Max Gekk <max.gekk@gmail.com>
2021-04-03 16:02:56 -04:00
OpenJDK 64-Bit Server VM 1.8.0_282-b08 on Linux 5.4.0-1043-azure
Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
[SPARK-29081][CORE] Replace calls to SerializationUtils.clone on properties with a faster implementation Replace use of `SerializationUtils.clone` with new `Utils.cloneProperties` method Add benchmark + results showing dramatic speed up for effectively equivalent functionality. ### What changes were proposed in this pull request? While I am not sure that SerializationUtils.clone is a performance issue in production, I am sure that it is overkill for the task it is doing (providing a distinct copy of a `Properties` object). This PR provides a benchmark showing the dramatic improvement over the clone operation and replaces uses of `SerializationUtils.clone` on `Properties` with the more specialized `Utils.cloneProperties`. ### Does this PR introduce any user-facing change? Strings are immutable so there is no reason to serialize and deserialize them, it just creates extra garbage. The only functionality that would be changed is the unsupported insertion of non-String objects into the spark local properties. ### How was this patch tested? 1. Pass the Jenkins with the existing tests. 2. Since this is a performance improvement PR, manually run the benchmark. Closes #25787 from databricks-david-lewis/SPARK-29081. Authored-by: David Lewis <david.lewis@databricks.com> Signed-off-by: Dongjoon Hyun <dhyun@apple.com>
2019-09-15 03:28:32 -04:00
Large Properties: Best Time(ms) Avg Time(ms) Stdev(ms) Rate(M/s) Per Row(ns) Relative
------------------------------------------------------------------------------------------------------------------------
[SPARK-34950][TESTS] Update benchmark results to the ones created by GitHub Actions machines ### What changes were proposed in this pull request? https://github.com/apache/spark/pull/32015 added a way to run benchmarks much more easily in the same GitHub Actions build. This PR updates the benchmark results by using the way. **NOTE** that looks like GitHub Actions use four types of CPU given my observations: - Intel(R) Xeon(R) Platinum 8171M CPU 2.60GHz - Intel(R) Xeon(R) CPU E5-2673 v4 2.30GHz - Intel(R) Xeon(R) CPU E5-2673 v3 2.40GHz - Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz Given my quick research, seems like they perform roughly similarly: ![Screen Shot 2021-04-03 at 9 31 23 PM](https://user-images.githubusercontent.com/6477701/113478478-f4b57b80-94c3-11eb-9047-f81ca8c59672.png) I couldn't find enough information about Intel(R) Xeon(R) Platinum 8272CL CPU 2.60GHz but the performance seems roughly similar given the numbers. So shouldn't be a big deal especially given that this way is much easier, encourages contributors to run more and guarantee the same number of cores and same memory with the same softwares. ### Why are the changes needed? To have a base line of the benchmarks accordingly. ### Does this PR introduce _any_ user-facing change? No, dev-only. ### How was this patch tested? It was generated from: - [Run benchmarks: * (JDK 11)](https://github.com/HyukjinKwon/spark/actions/runs/713575465) - [Run benchmarks: * (JDK 8)](https://github.com/HyukjinKwon/spark/actions/runs/713154337) Closes #32044 from HyukjinKwon/SPARK-34950. Authored-by: HyukjinKwon <gurwls223@apache.org> Signed-off-by: Max Gekk <max.gekk@gmail.com>
2021-04-03 16:02:56 -04:00
SerializationUtils.clone 4 4 0 0.0 4035677.0 1.0X
Utils.cloneProperties 0 0 0 0.0 43300.0 93.2X
[SPARK-29081][CORE] Replace calls to SerializationUtils.clone on properties with a faster implementation Replace use of `SerializationUtils.clone` with new `Utils.cloneProperties` method Add benchmark + results showing dramatic speed up for effectively equivalent functionality. ### What changes were proposed in this pull request? While I am not sure that SerializationUtils.clone is a performance issue in production, I am sure that it is overkill for the task it is doing (providing a distinct copy of a `Properties` object). This PR provides a benchmark showing the dramatic improvement over the clone operation and replaces uses of `SerializationUtils.clone` on `Properties` with the more specialized `Utils.cloneProperties`. ### Does this PR introduce any user-facing change? Strings are immutable so there is no reason to serialize and deserialize them, it just creates extra garbage. The only functionality that would be changed is the unsupported insertion of non-String objects into the spark local properties. ### How was this patch tested? 1. Pass the Jenkins with the existing tests. 2. Since this is a performance improvement PR, manually run the benchmark. Closes #25787 from databricks-david-lewis/SPARK-29081. Authored-by: David Lewis <david.lewis@databricks.com> Signed-off-by: Dongjoon Hyun <dhyun@apple.com>
2019-09-15 03:28:32 -04:00
Reference in a new issue Copy permalink