perf: cache layout access check

mweberxyz commented 7 months ago

Specifying a layout on render causes a synchronous fs.accessSync on every request. Cache the result of these lookups in LRU to avoid duplicate blocking checks.

Benchmarks (master)

fastify-ejs-local-layout.js: 84885.34 req/s
fastify-ejs-global-layout.js: 115680 req/s

Benchmarks (PR)

fastify-ejs-local-layout.js: 114592 req/s
fastify-ejs-global-layout.js: 116917.34 req/s

Checklist

[x] run npm run test and npm run benchmark
[x] tests and/or benchmarks are included
[x] commit message and code follows the Developer's Certification of Origin and the Code of conduct

gurgunday commented 7 months ago

Can you replace hashlru with toad-cache (LruMap) in another PR?

We try to use that for all the packages now, unless there is a significant perf regression

mweberxyz commented 7 months ago

Actually, just checked the PR again and it looks to me like this function gets called once?

Is that not the case?

It gets called a single time for a globally defined layout.

It gets called on every request (via layoutIsValid) for a reply-defined layout, ie -

reply.view('index-for-layout.ejs', { text: 'text' }, { layout: 'layout.html' })

mweberxyz commented 7 months ago

Marked as draft to let https://github.com/fastify/point-of-view/pull/416 and the subsequent toad-lru PR merge first to avoid conflict.

fastify / point-of-view