Real world performance metrics: java.io vs. java.nio (The Sequel)
About 275% faster for my particular use case
From the ever powerful yet flawed Wikipedia, there is a concept to help bring these metrics into focus:
Cēterīs paribus is a Latin phrase, literally translated as "with other things the same." It is commonly rendered in English as "all other things being equal." A prediction, or a statement about causal or logical connections between two states of affairs, is qualified by ceteris paribus in order to acknowledge, and to rule out, the possibility of other factors which could override the relationship between the antecedent and the consequent.Blah, blah, blah. OK, back to gathering more data with this in mind.
A ceteris paribus assumption is often fundamental to the predictive purpose of scientific inquiry. In order to formulate scientific laws, it is usually necessary to rule out factors which interfere with examining a specific causal relationship. Experimentally, the ceteris paribus assumption is realized when a scientist controls for all of the independent variables other than the one under study, so that the effect of a single independent variable on the dependent variable can be isolated. By holding all the other relevant factors constant, a scientist is able to focus on the unique effects of a given factor in a complex causal situation.
With a single set of 8 files from production webcasts, more results were captured in two series. The second series was measured immediately after the first series on physically separate copies of the files. Measurements were taken one fine evening last November on the production server described in the first post--activity was not too busy at the time, maybe 10% of capacity.
(Drum roll please...) The results:
| File Size (KB) | Speed (KBps) |
|||
| v2.2 (java.io) | v2.2 (java.io) | v2.4 (java.nio) | v2.4 (java.nio) | |
| 61,793 | 67,965 | 72,647 | 200,239 | 202,806 |
| 70,079 | 31,418 | 30,798 | 73,225 | 91,648 |
| 82,645 | 30,529 | 31,286 | 84,291 | 91,887 |
| 82,951 | 53,388 | 50,290 | 144,458 | 154,158 |
| 88,086 | 29,106 | 29,134 | 71,360 | 69,012 |
| 101,500 | 28,491 | 28,935 | 75,644 | 80,758 |
| 122,606 | 30,839 | 31,954 | 84,035 | 92,383 |
| 289,423 | 42,374 | 41,479 | 112,543 | 112,773 |

Interpretations:
- Much more consistent, although in hindsight I should have encoded a video from a single source to various different qualities. This would have made the number of index points consistent across each file.
- On average, java.nio performed 273% faster than java.io.
- The mean performance increase was 277%
- The minimum was 241%
- The maximum improvement was 288%
Re: Real world performance metrics: java.io vs. java.nio (The Sequel)
Re: Real world performance metrics: java.io vs. java.nio (The Sequel)
@Stu: It might be a dumb question. Sorry if it is :).. Can we use this same concept for a producer-consumer pattern? If we dont want to use heap for a very large quantum of produced data; we could put this down in a file using MBB; and read it later; may be from consumer? Does it really make a difference? Assuming both wil be in same application; We can keep something like; once the producer finishes with the first buffer; intimate the consumer to take it and it goes on? And maybe once all buffers are filled; intimate the consumer to destroy it after processing last buffer and producer can continue with a new one. Well; its not that always producers will stay ahead of consumer; At one point this guy will catch up i guess. This thing will be better in disk rather than putting it in memory and dealing with OOMs. Isnt it? (A particular case where we dont want to lose any data; which will be difficult to keep in-memory beause if producers are fast; going to get OOM)
Not really sure. Just asking..
