Module resolution

[sheplu]

Following the tweet by Marvin - and the subsequent article we should see how we can take that feedback into account and see how we can improve the performances around module resolution

• stacktrace / throwIfNoEntry in fs.stat
• cache when accessing file
• file extension

[marvinhagemeister]

FYI: It looks like only fs.statSync and fs.lstatSync support the throwIfNoEntry option. Can't find such a thing for the async variants.

[joyeecheung]

In the meeting we mentioned it might be possible to implement the sync stat functions with fast calls. The stats are assembled from a typed array, which can be updated just fine in fast calls without triggering allocations.

[joyeecheung]

It's also mentioned that fs.existsSync can be used, although it now still does an try-catch because we have a funny behavior that is pending to be deprecated: https://github.com/nodejs/node/blob/762a3a8ad925d56a12b43e0e7f7c811e93097784/lib/fs.js#L272-L277 technically I think we can still avoid that even without breaking it if we return false instead of just throwing in the validation helpers.

[tony-go]

I'll take a look at it in a couple of days

[tony-go]

In the meeting we mentioned it might be possible to implement the sync stat functions with fast calls. The stats are assembled from a typed array, which can be updated just fine in fast calls without triggering allocations.

Hey @joyeecheung 👋🏼

Do you mean using uv_fs_statfs without the SyncCall wrapper?

[debadree25]

In the meeting we mentioned it might be possible to implement the sync stat functions with fast calls. The stats are assembled from a typed array, which can be updated just fine in fast calls without triggering allocations.

I attempted something similar here nodejs/node#46345
I think this could be made slightly faster using internalBinding('stat') but haven't found any consensus yet on whether such a API is useful
@joyeecheung @tony-go