Attempt to Build Findings for Sustainability Considerations #142
StSchnell
started this conversation in
Random Chat
Replies: 2 comments 3 replies
-
Which profiler is this? |
Beta Was this translation helpful? Give feedback.
2 replies
-
Would bed interested in comparing .for each against a regular for loop as well as a for-of loop |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In the context of a sustainability analysis experiences are described here, based on the answers to a specific question. Furthermore an attempt will be made, to build findings for sustainability considerations. This bases of an analysis of a JavaScript library, which is mainly server-side used in business.
Sustainability Comparison of forEach and for-each-in Iterators of the Rhino JavaScript Engine
The Mozilla Rhino engine offers various options for working with indexed collections. One is the Array.prototype.forEach loop, known from the ECMAScript language specification. Another is the for-each-in statement from the ECMAScript for XML (E4X) specification. The Rhino engine is used in many business and enterprise products. It can be assumed that these iterators are often used in customer programming. From this perspective a consideration of performance and energy consumption is certainly a valuable aspect. The question is therefore asked: Which of the iterators of the Rhino engine is the more sustainable approach, forEach or for-each-in?
The following JavaScript test program was used to compare the two approaches:
There are three functions that are called by main function. The dummy function is only used for initialization. During my tests I noticed that the function called first always shows significantly poorer performance. To compensate this behavior the dummy function is called first. Their consumption has no effect on the following considerations.
Then there is the function _forEach, which contains Array.prototype.forEach, and _for_each, which contains the for-each-in statement. Both process an array of 50 numbers 10 million times. The high number of iterations is really necessary to get meaningful results. If the number is too low, the analysis tools may not recognize the execution of the functions.
Four approaches were used for this analysis:
Java Profiler
The first analysis was done with a Java profiler.
We see here that the for-each-in statement appears approximately 4.31 times more frequently in the samples.
JavaScript Profiler
The second analysis was done with a Rhino JavaScript profiler, which bases on the Java Profiler. This profiler was specially developed for use in platforms that use the Rhino Engine as the basis for customer coding.
Here is the for-each-in statement approximately 3.63 times more frequently in the samples. This result is similar to that of the Java Profiler, if a blind eye is turned.
Time Consumption
The third analysis was used to measure the time consumption of the functions.
Here needs the for-each-in statement approximately 2.95 times more time.
Energy Consumption
The fourth analysis was done with jPowerMonitor, a library for measuring energy consumption.
Here we can see that the for-each-in statement also consumes significantly more energy and therefore generates more CO2.
Conclusion
From these four analyses we can summarize that Array.prototype.forEach is in this case more performant than the for-each-in statement. In addition Array.prototype.forEach consumes significantly less energy than the for-each-in statement. A recommendation can be derived from this, to avoid the using the for-each-in statement if possible.
Analysis Basics
Measurement Methodology
The profiler measurements were made with Bellsoft JDK 22 in Windows 10. The energy consumption measurement were made with Bellsoft JDK 21.0.1 in Windows 10. Rhino Engine 1.7.14 was used in all measurements. No manual activities were executed on the system during the measurements. Background activities were possible, but were monitored with the Task Manager and none were detected. This means that a constant measuring environment can be assumed. All measurements were made ten times and then the average is here as an example quoted.
Code Analysis
The Mozilla Rhino scripting engine transforms the JavaScript code into Java bytecode, which will then be executed by Java. The Java source code can only be generated by decompiling. This automatically generated source code is not easy to read. But it can be very informative to see how the JavaScript code is transformed into Java code.
Experiences and Findings of Sustainability
Conclusion
The question raised, which of the iteration methods forEach or for-each-in was the more sustainable, could be answered.
In any case there have been some findings. It is always preferable to use several approaches in a sustainability analysis, to build a balance. Because there were no direct interdependencies visible between the analysis approaches, so that clear conclusions cannot be made from their relations. The use of a reference system can probably not often be avoided.
It can be assumed that libraries, that work in a similar way like the Rhino engine, can also be tested for sustainability using the same experiences and findings described here.
Beta Was this translation helpful? Give feedback.
All reactions