So, the overhead I'm referring to isn't so much stuff like function dispatch (which is almost immeasurable with the heavy lifting happening in C), but idiomatic overhead. Creating an anonymous function to map across a lazy sequence wrapping a persistent data structure doesn't have a chance in hell against a native for loop on a native vim list. I actually did quite a bit of optimization in this area (that's where chunked seqs came from), and it's quite usable for many tasks, but it's still potentially bottlenecking so I never really found myself "trusting" it for anything significant.
Of course, I am in a rather unique position of being able to bang out well optimized VimL in my sleep, so paradoxically that biases me against my own creation.
Grandparent was correct. Vim's basic completion is "similar words in the current file" (plus some other things), but omnicomplete is an arbitrary algorithm that can get pretty fancy. For example, in Ruby, omnicomplete on 3.14.tr will include truncate, while omnicomplete on [[1, 2]].tr will include transpose.
I doubt it. Spam bots are at the other end of the spectrum, with large numbers of short lived, seldom noticed accounts. This has to be about the Justin Biebers and Charlie Sheens.
There's lots of ways YouTube could marginalize H.264 without turning it into a full fledged game of chicken. They could make HD content exclusively WebM but still serve H.264 SD. They could prioritize WebM encoding so that there would be a delay before H.264 content was available (imagine getting told "this video is not yet available on your device" once every 6 months or so). They could make the most popular stuff in both formats but only offer WebM for stuff at the end of the long tail. They could offer a more favorable cut of ad revenue to content providers who opt out of H.264 (ostensibly because it saved on licensing fees).
Of course, I am in a rather unique position of being able to bang out well optimized VimL in my sleep, so paradoxically that biases me against my own creation.