
Security News
Static vs. Runtime Reachability: Insights from Latio’s On the Record Podcast
The Latio podcast explores how static and runtime reachability help teams prioritize exploitable vulnerabilities and streamline AppSec workflows.
performance-spy
Advanced tools
It'll override the implentation of your favorite libraries!
And will tell you how much performance they take, and you can improve their usage.
For example if you have in reselect a function that takes 1 seconds each time, and gets calculated 5 times instead of once, it'll show you which arguments caused the cache to expire.
Profilers work in samples, they check the stacktrace a few times in a ms, but in between there are lots of things you might miss and won't be able to find with it due to it.
Profilers will usually be less guidy, they won't show you, this cache selector doesn't work well and broken.
(Not an npm library yet, just a placeholder)
add to webpack.config.js:
alias: { /* my aliases */ ...require("performance-spy").spyWebpackAliases({ "redux-thunk": path.resolve("./node_modules/redux-thunk"), "reselect": path.resolve("./node_modules/reselect"), "re-reselect": path.resolve("./re-reselect-module"), }) }
it'll override redux/reselect with performance-spy libraries
add to your init.js file, before any usage of one of the libraries
require("performance-spy").enableSpying();
add to jest.config.js
moduleNameMapper: { // my name mappers... ...spyJesAliases("/node_modules", ["redux-thunk", "re-reselect", "reselect"]) }
add to jest.init require("performance-spy").enableSpying();
load a page, do some actions
run in f12 console:
getPerfSummary()
you'll get a summary of what had happend
load a page and prepare to do your action
run in f12 console
perfStatsReset()
do your action
run in f12 console
getPerfSummary
you'll see a summary of this action
If you have a function that you know it's slow, but you don't know which part you can use
const timer = startCustomTimer("measuring a")
// some actions
timer.end()
and then you'll see it as part of getPerfSummary
so you can divide and conquer your slow function until you find which part is slow:
const measureHeavy = startCustomTimer("heavy")
someHeavyStuff()
measureHeavy.end()
const measureLight = startCustomTimer("light")
someLightStuff()
measureLight.end()
const measureSuspect = startCustomTimer("suspicious")
SomeSuspiciousStuff()
measureSuspect.end()
and you'll get the answer which one is the slowing part? the heavy function? the suspicious? the light?
you can also provide data to it, for dynamic measure, to know which id had a slow transaction
const measureIdStuff = startCustomTimer("suspicious"+id)
heavyFunction(id)
measureIdStuff.end()
FAQs
Performance spy - spy on common libraries and check their performance
The npm package performance-spy receives a total of 1 weekly downloads. As such, performance-spy popularity was classified as not popular.
We found that performance-spy demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
The Latio podcast explores how static and runtime reachability help teams prioritize exploitable vulnerabilities and streamline AppSec workflows.
Security News
The latest Opengrep releases add Apex scanning, precision rule tuning, and performance gains for open source static code analysis.
Security News
npm now supports Trusted Publishing with OIDC, enabling secure package publishing directly from CI/CD workflows without relying on long-lived tokens.