Optimizing Stats objects by creating Date objects lazily #137
Description
What is the problem this feature will solve?
Making fs.stat calls faster.
What is the feature you are proposing to solve the problem?
There seem to be 4 Date objects being created per Stats object:
I think those should be created lazily, and cached after they are read the first time for maximum backwards compatibility.
In a little local benchmark creating the equivalent number of Date objects in a loop seems responsible for roughly ~15% of the time that fs.statSync spends, and all those Date objects probably still left garbage to be collected behind that my little for loop wasn't accounting for.
I'd imagine it's pretty rare that somebody needs to read all 4 of those Date objects, and I actually never read any of those, so I'd expect this optimization to potentially translate to a ~15% speedup or near that for stat calls for many people.
What alternatives have you considered?
No reasonable alternatives, the only ones I can think of are using process['binding']('fs') directly, or switching to another runtime.