Enumerable#include only uses indexOf as a short circuit; if indexOf
returns -1, it goes back and searches the whole container manually
with each.  This makes false results very slow; after scanning with
the fast, native indexOf, it goes back and does it the slow way.  Is
there a reason for this?

  function include(object) {
    if (Object.isFunction(this.indexOf))
      if (this.indexOf(object) != -1) return true;


  function include(object) {
    if (Object.isFunction(this.indexOf))
      return this.indexOf(object) != -1;

Better yet is to rebind this.include on the first call to eliminate
the Object.isFunction overhead, eg:

  function include(object) {
    if (Object.isFunction(this.indexOf))
      this.member = this.include = (function(object) {
        return this.indexOf(object) != -1;
      return this.include(object);

On a simple benchmark of searching Array([1,2,3,4]) 1000000 times, the
original code takes my system 9.7 seconds, eliminating the extra
search brings it down to 3.1 seconds, and after rebinding it's where
it should be: .121 seconds (FF3.6.8).

The only edge case I can think of is if indexOf is removed from the
object, which is pretty contrived.

Glenn Maynard

You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to