In 2014, the Policy Simulation Library [1] added a model called Tax-Simulator [2], which is a Python reimplementation of TAXSIM [3][4]. It is available as open-source [5], and designed to let researchers both change existing policy variables and implement new tax reforms in Python.
> Each year Americans spend over two billion hours and $30 billion preparing individual tax returns, and these filing costs are regressive. To lower and redistribute the filing burden, some commentators have proposed having the IRS pre-populate tax returns for individuals. We evaluate this hypothetical policy using a large, nationally representative sample of returns filed for the tax year 2019. Our baseline results indicate that between 62 and 73 million returns (41 to 48 percent of all returns) could be accurately pre-populated using only current-year information returns and the prior-year return. Accuracy rates decline with income and are higher for taxpayers who have fewer dependents or are unmarried. We also examine 2019 non-filers, finding that pre- populated returns tentatively indicate $9.0 billion in refunds due to 12 million (22 percent) of them.
test-queue supports minitest too, and follows the same basic design outlined in this article: a central queue sorted by slowest tests first, with test runners forked off either locally or on other machines to consume off the queue.
We use test-queue in a dozen different projects at GitHub and most CI runs finish in ~30s. The largest suite is for the github/github rails app which runs 30 minutes of tests in 90s.
The https://github.com/simeonwillbanks/busted gem provides some nice helpers around RubyVM.stat for finding cache invalidations. It can also take advantage of the dtrace/systemtap probes that shipped with ruby 2.1 (http://tmm1.net/ruby21-method-cache) which can be used as an alternative to the ftrace technique described in the blog post.
Before the release of 2.1.0, funny_falcon, samsaffron and I developed a patch that removes the global method cache in favor of a local method cache inside each class. (This was originally proposed for upstream inclusion in https://bugs.ruby-lang.org/issues/9262).
The patch has been running in production on GitHub's servers for over a year, and provides the benefits of a high cache-hit rate without the need for manual tuning. I recently ported this patch to ruby 2.2 as well and it is available in this squashed commit: https://github.com/github/ruby/commit/bd002fc9fc3c7236395df2...
Copying `/usr/bin/gdb` and `/usr/libexec/gdb/gdb-i386-apple-darwin` from an OSX Lion installation is one way to get a functional gdb on Mountain Lion or Yosemite.
We implement preload_all, which loops over app/{models,controllers}/ and requires everything. This method is generally called from config.ru, and happens in the unicorn master before it forks off workers.
Unicorn pre-forks workers upfront. New processes are not created per request.
posix-spawn is also only useful for fork+exec, where the new process starts executing a new binary. This is not the case in unicorn or resque, where the child processes actually need to be copies of the parent.
We're currently using posix-spawn in albino and grit, which execute external commands like `pygmentize` and `git`
The reason fork is so slow on Linux is because the default page size is 4k. This means for a 300MB process, 76800 page table entries have to be copied during the fork.