Simple. It isn't more complicated. ;) You gain an easier way to read an MD5 file. The idea that you can decode the file in the open statment is quite nice, because now you can pass that file handle to anything expecting a file handle without those functions needing to worry that it is encrypted. This can be significant, or it can be meaningless. It realy depeneds on your need, if you have a need to gzip or md5 a file that you then want to be able to open and just use the file handle as normal, this is very usefull. If your code is going to look ilke your benchmark then it is 50/50 ;) Thats what makes perl fun, choices.
| [reply] |
So I decided to re run your benchmark after making both pieces of code as close to possible as identical. Below are the results and the code, it would appear that it makes no differnce which to choose, both were faster once, and they actualy tied once. I took them tieing on the
third run to be a sign ;)
| [reply]
[d/l]
[select] |
I don't agree with more complicated. Try to implement each of the filtering layers yourself. Probably each filter will need a totally different approach, whereas the PerlIO are very much the same in use.
CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law
| [reply] |
Good question. So, why do you use Perl, as it's both slower and more complicated to implement than C? | [reply] |