not all code is parsed.
-
-
it's poetic and illustrates why the original chart is a poor analysis of the situation ;)
1 reply 0 retweets 1 like -
this is nuanced, but the generality of the cost of parse time stands on its own.
3 replies 0 retweets 1 like -
not true in practice. https://github.com/nolanlawson/optimize-js … is one reason.
2 replies 1 retweet 3 likes -
Replying to @wycats
that's an interesting reading of that result, which is about code that then has to be parsed anyway
@samccone@tbreisacher@tdreyno1 reply 0 retweets 1 like -
claiming that JS parse costs are non-trivial is surprising. can u give a better justification?
@samccone@tbreisacher@tdreyno2 replies 0 retweets 0 likes -
a lot of times a particular payload is already being highly lazy-parsed. In that case 1/
1 reply 0 retweets 1 like -
removing a lot of code has very limited impact on end-to-end time. 2/
1 reply 0 retweets 1 like -
this is something I've seen repeatedly in the real world after weeks or months of efforts to 3/
1 reply 0 retweets 1 like
strip down code size; identifying which code is being parsed and which is being evaluated 4/
-
-
is critical for understanding whether a huge effort to cut down code size will have the expected 5/
1 reply 0 retweets 2 likes -
effect on end-to-end time. Again, I've seen weeks of completely wasted time in the real world 6/6
1 reply 0 retweets 2 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.