On Feb 7, 12:21 am, kangax <[email protected]> wrote:
> On Feb 6, 7:36 am, ColinFine <[email protected]> wrote:
>
>
>
> > On Feb 5, 9:29 pm, Michael <[email protected]> wrote:> Thank you all
> > - Kangax's low profile technique works like a champ.
>
> > > Walter Lee: Regular expressions hurt my head. I will get there one
> > > day.
>
> > > The actual thing I am working on take about 100 alpha/numeric
> > > sequences of no real logical order... so making it in regular
> > > expression would take far longer (for me) then juts stubbing the 100
> > > sequences in there.
>
> > In Perl, I would not use regular expressions for this at all, but a
> > hash:
>
> > (equivalent of)
> > var hash = {V30000: true, B47242:true, V54000:true};
>
> > function checkValid(value)
> > {
> > return hash[value];}
>
> > (or 'return hash[value] == true' if you're picky).
>
> > This is a good idea in Perl because the language is optimised for
> > accessing hash values: I don't know how true that is in javascript.
>
> I'm pretty sure property lookup is faster than regexp in Javascript
> too.
It doesn't take much to test. Using a set of 1,000 values and looping
through 10,000 lookups took about 45ms in Firefox on a laptop with a
1GHz processor regardless of which method was used. The regular
expression version was generally faster in Safari, however both were
still generally less than 45ms.
The biggest hit to performance is forming the object, either a
delimited string or JSON that can be converted to an object.
The bottom line is that performance is an insignificant criterion in
this case.
> The only downside to this approach is that there's no reliable
> (native) "hash" structure in Javascript.
Some would argue that there is no Hash at all, but there are objects
that can be made to behave a bit like Hashes in other languages. :-)
> There also needs to be a
> boolean type conversion in your example, so that the function
> consistently returns either `true` or `false` (and not, say,
> `undefined` - for missing members).
A "falsey" or not true value may be sufficient, but since the value of
the object property is only used for comparison, it may as well be
boolean true. It could just as easily be 1 or 'hey' or any non-falsey
value if it served some other purpose.
Overloading of the property value might be seen as a good thing - or
not. It isn't possible with the regular expression method (well, it
is possible but requires more logic such as a comparison function but
that is getting well away from the intention of the OP). That might
be seen as a better thing.
> Regular property lookup is
> unreliable in such way that it takes object's prototype chain into
> account; That means there could be a conflict with
> `Object.prototype.*` properties - e.g.: `isValid('toString')` would
> return `Object.prototype.toString` which is a Function object and just
> like any object - type converts to `true` : )
The general issue is discovery of property names on the inheritance
chain that match tested values. Adding a "hasOwnProperty" doesn't
slow performance much (not noticeable in either browser I tested) and
logically may speed it up - it's an extra function call but doesn't
search the [[prototype]] chain.
> In more generic method,
> it would probably be a good idea to use
> `Object.prototype.hasOwnProperty`, but in this case, strict equality
> operator would do:
>
> var isValid = (function(){
> var hTable = { "V3000": true, "B47242": true, "V54000": true }
> return function(value) {
> return hTable[value] === true;
> // return Object.prototype.hasOwnProperty.call(hTable, value);
> }
>
> })();
Given that the difference in performance is negligible[1], a more
important criterion is the difference between generating a delimited
string (something most databases are very good at) compared to a JSON
object (which only some are good at and is more complex in general).
Compare generating the JSON string:
'{ "V3000": true, "B47242": true, "V54000": true }'
to the delimited string:
"V3000 B47242 V54000"
I know which one is simpler to generate and debug - of course the OP
is free to choose.
1. It might be in IE, I didn't test it. My impression is that JScript
is pretty quick with native code.
--
Rob
--~--~---------~--~----~------------~-------~--~----~
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---
