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;
becomes
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
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en.
