npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

fast-boot

v1.0.7

Published

Speeding up node boot time by caching for filesystem location of node modules

Downloads

619

Readme

NPM version License

fast-boot

When Node.js starts, a lot of the time is wasted on loading module files. Of the module loading time, most of the work is actually searching for the module file on the filesystem. When you require a module, node will look for it at the node_modules folder relative to the requesting module. If not found there, it will start stepping up the folder hierarchy looking for the module in each of the parent folders node_modules folder.

This search scheme makes node.js do a lot fs.statSync operations - an operation that throws an exception is the module file does not exist.

Fast boot caches the location of module files those speeding the loading of the node.js process. By caching the locations, we reduce the number of io operations significantly.

For example, loading of an Express application (with no other modules) without fast-boot compared to with fast-boot -

              | without fast-boot   | with fast-boot

----------------- | ------------------- | --------------- fs.statSync | 713 | 0 fs.readFileSync | 152 | 62 fs.existsSync | 7 | 103 loading time | 93 mSec | 60 mSec

Note that the loading times are measured on a Mac Pro with SSD - on an actual VM running on hardware with spin disk the loading times will be considerably larger.

The module hooks into the node module 'module' and wraps the _resolveFilename method, caching the files it finds in order to improve node loading performance. Node does tons of file lookups as it resolves modules and does not cache the found file locations.

fast-boot caches only modules located in the the projects node_modules directory.

fast-boot supports two patterns of working:

cache only

The first time the application runs, fast-boot learns what modules are loaded and saves the list of those modules as a cache file (located by default in the tmp folder). The second time the application loads it uses the cache file and loads faster. It is assumed the cache file is located on a read/write enabled drive.

startup and cache file

We can also improve the performance of the first time the application loads using a startup file. The startup file is assumed to be created using a build step and distributed with the application sources, assumed to be read-only. To create the startup file, load the application with all the modules and call saveStartupList(). By default, the startup file is saved in the project node_modules folder.

Once the application loads using the startup file, any additional modules loaded not in the startup file will cause fast-boot to save a cache file in tmp.

Reference:

nodeModuleCache.start([opts])

Starts the caching

var nodeModuleCache = require("fast-boot");
nodeModuleCache.start(opts);

Start accepts an options parameter with two options

  • cacheFile - alternate cache file location. Defaults to {os.tmpdir()}/module-locations-cache.json
  • startupFile - alternate startup file location. Defaults to ./node_modules/module-locations-cache.json, relative to the process.cwd()
  • cacheKiller - used to invalidate the cache. Normally one will pass the application version number assuming that a different version
  • statusCallback - callback function called each time fast boot loads or saves. function(message) may have different version of dependencies making modules located in different locations. The default is the version number from package.json, if one exists

nodeModuleCache.stop()

stops the module

nodeModuleCache.stop();

nodeModuleCache.saveCache(callback)

saves the cache file. Callback is called after completed save with signature function(err) {}

nodeModuleCache.saveCache();

nodeModuleCache.saveStartupList(callback)

saves the startup file. Callback is called after completed save with signature function(err) {}

nodeModuleCache.saveStartupList();

nodeModuleCache.loadModuleList()

reloads the modules list from the cache file (if exists) or the startup file (if exists)

nodeModuleCache.loadModuleList();

nodeModuleCache.stats()

returns a statistics object about the caching effectiveness. The stats object include the following members

  • cacheHit - the number of modules who's locations were found in the cache
  • cacheMiss - the number of modules who's locations were not found in the cache - and were added to the cache file
  • notCached - the number of modules not to be cached - either not in a node_modules folder or not under process.cwd()
  • cacheKiller - the current value of the cache killer
  • statusCallback.startupFile - most recent status of loading a startup file
  • statusCallback.cacheFile - most recent status of loading a cache file
var stats = nodeModuleCache.stats();
console.log(stats.cacheHit);
console.log(stats.cacheMiss);
console.log(stats.notCached);