Andrew Pontious:
Even though I wasn’t trying to finalize the design or the APIs yet, for each new area I pulled out, I found I could refine the previously-extracted areas. Exposed properties that before were accessed seemingly at random, I could now see were only used by one of the specific areas I’d pulled out, and only at specific times. I could start to move properties around between the extracted classes, cut and paste them where they should go. I could move closer to the encapsulation I wanted.
All without breaking anything, because I was taking such tiny, straightforward, safe steps.
That meant, by the time everything was extracted, I was actually much closer to a final design than I had any right to be, given initial conditions.
I have found this to be true as well.
Craft Programming Refactoring
Raymond Hettinger (slides):
Python’s dictionaries are stunningly good. Over the years,
many great ideas have combined together to produce the
modern implementation in Python 3.6.
This fun talk uses pictures and little bits of pure python
code to explain all of the key ideas and how they evolved
over time.
Includes newer features such as key-sharing, compaction, and versioning.
Brandon Rhodes:
Since my “Mighty Dictionary” talk at PyCon 2010, the Python dictionary has evolved dramatically. Come learn about all of the the improvements, up to and including the re-architecture that has just landed with Python 3.6! The talk will discuss iterable views, the dictionary’s dedicated comprehension syntax, random key ordering, the special key-sharing dictionary designed to underlie object collections, and, most famously of all, the new “compact dictionary” that cuts dictionary storage substantially — and carries a fascinating side-effect.
Each new feature that the talk discusses will be motivated by considering the trade-offs inherent in hash table data structure design, and followed up with hints about how you can now use the dictionary even more effectively in your own code!
Via Jake VanderPlas (via Hacker News):
One piece both mention is the addition in Python 3.6 of a private dictionary version to aid CPython optimization efforts […] “every dictionary has a version number, and elsewhere in memory a master version counter.”
PEP 509:
Python is hard to optimize because almost everything is mutable: builtin functions, function code, global variables, local variables, … can be modified at runtime. Implementing optimizations respecting the Python semantics requires to detect when “something changes”: we will call these checks “guards”.
The speedup of optimizations depends on the speed of guard checks. This PEP proposes to add a private version to dictionaries to implement fast guards on namespaces.
Previously: PyPy’s Hash Table Implementation, Python’s Dictionary Implementation.
Algorithm Language Design Optimization Programming Python Security
Saam Barati et al.:
This post describes the development of our first ES6 benchmark, which we call ARES-6. We used ARES–6 to drive significant optimization efforts in JSC, and this post describes three of them: high throughput generators, a new Map/Set implementation, and phantom spread. The post concludes with an analysis of performance data to show how JSC’s performance compares to other ES6 implementations.
[…]
The figure above shows the overall ARES-6 scores in three different browsers: Safari 11 (13604.1.21.0.1), Firefox 53.0.3, and Chrome 58.0.3029.110. Our data shows that we’re nearly to 1.8x faster than Chrome, and close to 5x faster than Firefox.
Compiler iOS iOS 11 JavaScript Mac macOS 10.13 High Sierra Optimization Programming Safari WebKit
Russ Bishop:
This might surprise you: the size of some types can be zero but the stride will always be at least 1 byte. Having types take up at least 1 byte means you don't need a bunch of special casing everywhere you deal with memory to avoid calling malloc(0). This does mean an array of 100 zero size types allocates 100 bytes that are never read or written.
Language Design Programming Swift Programming Language
Dan Luu:
The most cited AskTog page on the topic claims that they’ve spent $50M of R&D and done all kinds of studies; the page claims that, among other things, the $50M in R&D showed “Test subjects consistently report that keyboarding is faster than mousing” and “The stopwatch consistently proves mousing is faster than keyboarding.”. The claim is that this both proves that the mouse is faster than the keyboard, and explains why programmers think the keyboard is faster than the mouse even though it’s slower. However, the result is unreproducible because “Tog” not only doesn’t cite the details of the experiments, Tog doesn’t even describe the experiments and just makes a blanket claim.
[…]
Unlike claims by either keyboard or mouse advocates, when I do experiments myself, the results are mixed. Some tasks are substantially faster if I use the keyboard and some are substantially faster if I use the mouse. Moreover, most of the results are easily predictable (when the results are similar, the prediction is that it would be hard to predict).
[…]
I didn’t realize that scrolling was so fast relative to searching (not explicitly mentioned in the blog post, but 1⁄2 of the text selection task). I tend to use search to scroll to things that are offscreen, but it appears that I should consider scrolling instead when I don’t want to drop my cursor in a specific position.
Keyboard Mac Mouse Programming
