In the new year, I plan on archiving the repositories below. Because I plan on only archiving the repositories, any project that depends on any of these projects will continue to work. However, I will no longer be accepting issues or pull requests and will never tag a new release.
The reality of each of the projects listed below is that I've almost completely ignored issues and pull requests for
Some quick thoughts on https://twitter.com/dan_abramov/status/884892244817346560. It's not ignorant at all to ask how browser vendors approach performance. On the V8 side we've discussed bytecode precompilation challenges a few times this year. Here's my recollection of where we stand on the idea:
JavaScript engines like V8 have to work on multiple architectures. Every version of V8 is different. The architectures we target are different. A precompiled bytecode solution would require a system (e.g the server or a CDN) to generate bytecode builds for every target architecture, every version of V8 supported and every version of the JavaScript libraries or bundles bytecode is being generated for. This is because we would need to make sure every user accessing a page using that bytecode can still get the final JS successfully executed.
Consider that if a cross-browser solution to this problem was desired, the above would need to be applied to JavaScriptCore, SpiderMonkey and Chakra as well. It would need to ca
| <!-- | |
| This demo shows two ways to detect changes to a DOM node `.textContent`, one | |
| using a `MutationObserver` and the other using an ES2015 `Proxy`. | |
| From testing, a `Proxy` appears to be 6-8x faster than using a MO in Chrome 50. | |
| **Update**: removing the `Proxy` altogether speeds up the MO to be inline with the Proxy. | |
| This has something to do with how the browser queues/prioritizes Proxies over MO. |
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent
This page collects common comments made during reviews of Go code, so that a single detailed explanation can be referred to by shorthands. This is a laundry list of common mistakes, not a style guide.
You can view this as a supplement to http://golang.org/doc/effective_go.html.
Please discuss changes before editing this page, even minor ones. Many people have opinions and this is not the place for edit wars.
| ,_---~~~~~----._ | |
| _,,_,*^____ _____``*g*\"*, | |
| / __/ /' ^. / \ ^@q f | |
| [ @f | @)) | | @)) l 0 _/ | |
| \`/ \~____ / __ \_____/ \ | |
| | _l__l_ I | |
| } [______] I | |
| ] | | | | | |
| ] ~ ~ | | |
| | | |
| -- Two dashes start a one-line comment. | |
| --[[ | |
| Adding two ['s and ]'s makes it a | |
| multi-line comment. | |
| --]] | |
| ---------------------------------------------------- | |
| -- 1. Variables and flow control. | |
| ---------------------------------------------------- |
| Latency Comparison Numbers (~2012) | |
| ---------------------------------- | |
| L1 cache reference 0.5 ns | |
| Branch mispredict 5 ns | |
| L2 cache reference 7 ns 14x L1 cache | |
| Mutex lock/unlock 25 ns | |
| Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
| Compress 1K bytes with Zippy 3,000 ns 3 us | |
| Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
| Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
| using System; | |
| using System.Collections; | |
| using System.Collections.Generic; | |
| namespace DictionaryTest | |
| { | |
| /// <summary> | |
| /// Dictionary of objects, stored by key</summary> | |
| /// <typeparam name="TKey">Type of objects used</typeparam> | |
| /// <typeparam name="TValue">Type of objects stored</typeparam> |