Bug/Improvement: hostname resolution very slow - maybe cache it

[DarkLiKally]

Describe the bug
I'm using tslog in a AWS lambda envrionment - but the thing is also occuring locally. When you log many things the most of the execution time of our function is dedicated to the getHostname / hostname() function from the node:os package.

To Reproduce
Steps to reproduce the behavior:

1. setup tslog in a default configuration
2. log many messages
3. attach a profiler to the node process (--inspect -> chrome://inspect -> profile)
4. see the results

The hostname is resolved again and again for each log obejct in the _buildLogObject function

Expected behavior
Maybe it is better to cache the hostname for each logger instance or maybe refresh it in time frames or maybe add an option to enable/disable caching of it. And not evaluate it always again since the node os api for it is pretty slow compared to all other code thats run. It makes up 80 to 90 % of cpu time in my profiler runs for about 10.000 log messages.

Node.js Version
16

OS incl. Version
windows 10 x64 / ubuntu, wsl 8 / aws linux for lambda

[terehov]

Thanks, that’s a really good finding! I’ll fix it soon. 👍🏻

[DarkLiKally]

@terehov thanks :) another quick note:
The Logger constructor also resolves the hostname - when creating child loggers for each request in services injected via DI (we have many scoped services) there's also a good amount of requests to the os.hostname().
Maybe that's also good to cache.
For performance that is not a super deal in this case, it's not as much as for each log message but it could improve about 3 - 5 milliseconds in our situation per request (we would come down from ~15 ms to about 8 - 11 ms).

We could of course switch to some cached loggers, or a static instance or something, but we wanted to make use of the inherited settings with the requestId.

[terehov]

@DarkLiKally Here you go, give it a try :-)

https://github.com/fullstack-build/tslog/releases/tag/v3.3.2