One of the key metrics when writing code is speed. But there is no convenient way to measure the speed of your code efficiently so far. Chrome and other browsers do have APIs (new Date(), performance.now(), console.time) that let you put them around your code, then you will do a simple calculation to find out the diff, like: t2 - t1
Another Approach
That works for an instant need when you want to know how much time a block of code executes. However, when you want to do more, you will have to write some util functions or library.
Performance.now() is a high resolution timer API that you can rely on to measure time difference. Many modules were created to utilize that API, one of them is mstime - https://github.com/ngduc/mstime - a lightweight module (2 KB gzip) to measure and visualize code performance in (ms).
Usage
Now with the help of the mstime module, you can write simple code like this:
mstime.start("codeblock1");
myFunction();
console.log( mstime.end("codeblock1") );
Nothing is new so far. Until you take a closer look a the output:
{
entries: [
{ start: 41991120.53, end: 41991133.04, diff: 12.50 }
],
plugins: { ... },
last: 12.50,
sum: 12.50,
avg: 12.50
}
That open the door to opportunities! You now have control on the dataset of every measurement, plus useful calculations like: sum, average (avg), last value & a plugin system!
There are a couple of built-in plugins like: calculating for trimmed mean (e.g. get 90 percentile of data), persisting data to localStorage, plotting data to chart, etc.
Example of using the chartist plugin to plot time data:
Now it's your turn to utilize the dataset you captured!
Please comment below, let me know your ideas, feedbacks or anything you like to discuss.
Top comments (17)
Lighting McQueen fast
Other devs can read my code very fast 😁
I presume you talk about browsers, for backend we have performant choices.
You should also check out Flamegraphs charts, and Dev tools have very mature performance monitoring and analysis tools.
Having the words JavaScript and performance in the same article feels .. weird.
Engines developers, same as JVM and probably .net optimize their engines based on most common practices, so if you write good enough code it will run fast. V8 team have some good talks on youtube about this topic.
Actually, it's not weird. APM for NodeJS is a whole business.
If a team wants performance for its key components and paths will not use nodeJS, it can only go so far ...
When doing JS benchmarks ...
youtube.com/watch?v=r76ZjdzFExg
Great talk & insight. It's like a C dev explained JS perf at byte code level.
AFAIR he worked on the V8 JS engine ;)
Benchmarking is a skill on its own. Today's JS engine use a lot of shortcut and optimization, which impact performance tests.
It's also a balance between clear and maintainable code against fast and optimizable code. With modern computer power, I would largely prefer the first side.
Also, to measure time I would use developer.mozilla.org/docs/Web/API...
Right. console.time is useful for one time use.
If you want to capture measured data, store, analyze, visualize them, etc. then that's not enough.
As fast as your CPU. The performance limitations are CPU, GPU, all sort of processors but not my dear code. 🙌
Maybe DB connections, queries, rendering libs/functions, array lookup, etc. So many factors to measure.
Can't wait for native JS become true (WebAssembly, asm.js. Nectarjs looks promising).
Meanwhile, I will stick with JS :)
Wasm is not a replacement for JS unfortunately
I agree.
@nektro that's just political propaganda.
In reality, it will probably replace it, not only in libraries but all the way to the glue code.
Just needs more features than the MVP release we have now.
But they are definitely on the way.
My sarcasm detector isn't working right now...