[dmethvin]

If you've got some ideas a ticket at bugs.jquery.com would be a great place to start, with whatever analysis you have.

Remember, however, that many of your "comparable" test cases are making assumptions that jQuery can't make. For example, .show() sets the display property back to what it was before a previous .hide(), to do that it has to query the display property when hiding. If you try some ideas for fixes, the unit tests should indicate whether you've run afoul of such problems.

Is the performance of .show()/.hide() causing issues? Under what conditions?

[Jakob]

I agree with hide() and show(). Their performance is not that important since they are a swiss army knife and hopefully not used on too many elements at a time. The bad performance of .css() in the jsperf above is strange, though.

Profiling shows that it is not one big function but many small which accumulate. The camelCase function alone takes 3% of the speed in Chrome, the internal access() structure takes nearly half the time itself.

Speed could be achieved with the byte cost of specialised functions for easy cases like css(key, value) where you can skip most of the checks and queuing.

This shortcut for show/hide is roughly 16x faster and should remain more or less so even after extending it to cache the previous style and adding common exceptions for <tr>, !important, etc. Shortcuts like those could be used if it is clear that the chosen function signature is very easy like $('p').css('display', 'none') so all other checks can be skipped but would add to the payload of jQuery.

    $.fn.cssDisplay=function(show) {
      var d=show?'block':typeof show==='undefined'?'':'none',
        length=this.length, i=0;
      for(;i<length;) {
        this[i++].style.display=d;
      }
      return this;
    }

I’ll have a look into a more generic and faster .css() solution.