Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Javascript (http://www.velocityreviews.com/forums/f68-javascript.html)
-   -   Object Hash vs. object Array preference (http://www.velocityreviews.com/forums/t921279-object-hash-vs-object-array-preference.html)

VK 11-11-2005 08:22 PM

Object Hash vs. object Array preference
 
Hello,
In my object I have getDirectory() method which returns 2-dimentional
array
(or an imitation of 2-dimentional array using two JavaScript objects
with auto-handled length property - please let's us do not go into an
"each dot over i" clarification discussion now - however you want to
call - you call it ;-)

array[0] contains records of all files in the current dir.
array[1] contains records of all subs in the current dir

Each records is in its turn is an array of 6 elements: file/folder
name, size, type, attributes, lastModified date, lastModified time.

Tking into account that someone will need to build a dialog interface
over this data IMHO array structure is the most suitable ('cause of
sorting issue).

Or a custom object on each directory entry still would be more
flexible? What would you personally prefer to get out of the functiuon
for easier programming?


Thomas 'PointedEars' Lahn 11-11-2005 08:41 PM

Re: Object Hash vs. object Array preference
 
VK wrote:

> In my object I have getDirectory() method which returns 2-dimentional
> array
> (or an imitation of 2-dimentional array using two JavaScript objects
> with auto-handled length property - please let's us do not go into an
> "each dot over i" clarification discussion now - however you want to
> call - you call it ;-)


I can accept the term "2-dimensional array" for brevity, provided that
each element has the same number of subelements.

> array[0] contains records of all files in the current dir.
> array[1] contains records of all subs in the current dir
>
> Each records is in its turn is an array of 6 elements: file/folder
> name, size, type, attributes, lastModified date, lastModified time.
>
> Tking into account that someone will need to build a dialog interface
> over this data IMHO array structure is the most suitable ('cause of
> sorting issue).


I don't understand this argument. What has sorting to do with it?

> Or a custom object on each directory entry still would be more
> flexible? What would you personally prefer to get out of the functiuon
> for easier programming?


I'd prefer an Object-based object here since it is more difficult to
remember the index of the array element than the meaningful identifier
of the property. If needed later, an Array object can be extended to
a collection so that both access methods can be used.


PointedEars

VK 11-12-2005 11:31 AM

Re: Object Hash vs. object Array preference
 
> > VK wrote:
> > Tking into account that someone will need to build a dialog interface
> > over this data IMHO array structure is the most suitable ('cause of
> > sorting issue).

..
> Thomas 'PointedEars' Lahn wrote:
> I don't understand this argument. What has sorting to do with it?


I meant to say that you cannot sort hash keys (object properties,
collection items - the Legion is its name) but you can sort arrays.
Need to admit though that in case like
record[e1, e2, e3, e4, e5] > sort all records by e4
I'm pretty cloudy about the best accepted mechanics and therefore I'm
not sure what to serve better: an Object or an Array. I used to handle
such issues on server-side through mySQL where the boring part is done
automatically on the background.
..
> Thomas 'PointedEars' Lahn wrote:
> I'd prefer an Object-based object here since it is more difficult to
> remember the index of the array element than the meaningful identifier
> of the property. If needed later, an Array object can be extended to
> a collection so that both access methods can be used.

That's not so much a question of usability but a question of
productivity.
Firstly the served object will be used for LOOKUP operations
exclusively (you cannot delete files/properties or add new ones here).
Secondly it will be used for LOOKUP operations very intensively. On a
big directory (over 100 files) display/sorting/selection will take
thousands of lookups so even 1ms difference will add up easily. I guess
it brings up the old question: is there any productivity difference
between Object and Array for lookup operations?


Lasse Reichstein Nielsen 11-12-2005 11:59 AM

Re: Object Hash vs. object Array preference
 
"VK" <schools_ring@yahoo.com> writes:

> I meant to say that you cannot sort hash keys (object properties,
> collection items - the Legion is its name) but you can sort arrays.


Sorting implies ordering, which again implies indexability by counting
numbers, so yes, array elements can be sorted, rearranging their
property names. There is no ordering of general properties of objects,
so it's not even possible to define a notion of sorting on them.

> Need to admit though that in case like
> record[e1, e2, e3, e4, e5] > sort all records by e4


Not understood. If each record is a five element array, and you want
to sort it by its fourth element, then I'd do something like:
---
// generic comparison function
function cmp(a,b) {
return (b<a)-(a<b);
}

// creates function that compares property prop of arguments.
function cmpProperty(prop) {
return function (a,b) {
return cmp(a[prop],b[prop]);
};
}

// sort records by fourth element.
records.sort(cmpProperty(3));
---

> I'm pretty cloudy about the best accepted mechanics and therefore I'm
> not sure what to serve better: an Object or an Array.


Doesn't matter. You compare a property of the object, whether it's
called "3" or "foo" is irrelevant. So if you use the record anywhere
else, use meaningful names.


> I guess it brings up the old question: is there any productivity
> difference between Object and Array for lookup operations?


That depends on the implementation of Javascript it is running on.

A quick test:
---
function timeLookup(obj,prop, N) {
var t0 = new Date();
var x;
while(N--) {
x = obj[prop];
}
var t1 = new Date();
return t1-t0;
}

var N = 1000000;
var a = ["lal","lal","lala","lalala","lalalaalla"];
var t0 = timeLookup(a,"3", N);
var t1 = timeLookup(a,3, N);

var o = {"diller":"lal","daller":"lal","y":"lala","3":"lal ala",
"anguish":"lalalaalla"};
var t2 = timeLookup(o, "3", N);

var o2 = {"diller":"lal","daller":"lal","y":"lala","x":"lal ala",
"anguish":"lalalaalla"};
var t3 = timeLookup(o2, "x", N);

var o3 = {"diller":"lal","daller":"lal","y":"lala",
"dallerdallerdaller":"lalala","anguish":"lalalaall a"};
var t4 = timeLookup(o3, "dallerdallerdaller", N);

[t0,t1,t2,t3,t4]
---
gives the following results (times in ms):
array["3"] array[3] object["3"] object["x"] object["daller...."]
Opera 922 766 906 797 843
IE 6 906 891 891 937 1093
FF 746 406 750 625 906

So, of these, only Firefox seems to have a significantly more
efficient array lookup than property lookup, but longer property
names makes for longer lookup times.

It should probably also be tested on objects/arrays with lots
of properties, not just five.

Both Opera and Firefox seems to take extra time when the property is a
string containing a number literal, even when used on an object, not
an array. One can wonder why :)

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

VK 11-12-2005 02:03 PM

Re: Object Hash vs. object Array preference
 

> Lasse Reichstein Nielsen wrote:
> If each record is a five element array, and you want
> to sort it by its fourth element, then I'd do something like:
> ---
> // generic comparison function
> function cmp(a,b) {
> return (b<a)-(a<b);
> }
>
> // creates function that compares property prop of arguments.
> function cmpProperty(prop) {
> return function (a,b) {
> return cmp(a[prop],b[prop]);
> };
> }
>
> // sort records by fourth element.
> records.sort(cmpProperty(3));


Rather elegant but requires Object<>Array back and forth casting which
will swallow any productivity difference advantages between of them ?

> A quick test:
> ---
> function timeLookup(obj,prop, N) {
> var t0 = new Date();
> var x;
> while(N--) {
> x = obj[prop];
> }
> var t1 = new Date();
> return t1-t0;
> }
>
> var N = 1000000;
> var a = ["lal","lal","lala","lalala","lalalaalla"];
> var t0 = timeLookup(a,"3", N);
> var t1 = timeLookup(a,3, N);
>
> var o = {"diller":"lal","daller":"lal","y":"lala","3":"lal ala",
> "anguish":"lalalaalla"};
> var t2 = timeLookup(o, "3", N);
>
> var o2 = {"diller":"lal","daller":"lal","y":"lala","x":"lal ala",
> "anguish":"lalalaalla"};
> var t3 = timeLookup(o2, "x", N);
>
> var o3 = {"diller":"lal","daller":"lal","y":"lala",
> "dallerdallerdaller":"lalala","anguish":"lalalaall a"};
> var t4 = timeLookup(o3, "dallerdallerdaller", N);
>
> [t0,t1,t2,t3,t4]
> ---
> gives the following results (times in ms):
> array["3"] array[3] object["3"] object["x"] object["daller...."]
> Opera 922 766 906 797 843
> IE 6 906 891 891 937 1093
> FF 746 406 750 625 906
>
> So, of these, only Firefox seems to have a significantly more
> efficient array lookup than property lookup, but longer property
> names makes for longer lookup times.


Wow: double speed gain on Array with FF. These are 1-10 seconds speed
gain for application I guess - if you manage to stay within Array only.
IE seems rather indifferent but still just a bit quicklier. So I'd
explore Array-only solutions first if any is possible.

> It should probably also be tested on objects/arrays with lots
> of properties, not just five.


That's not my case, but I'd welcome any volunteer ;-)

> Both Opera and Firefox seems to take extra time when the property is a
> string containing a number literal, even when used on an object, not
> an array. One can wonder why :)


Was that a rhetorical question? :-)
Naturally arr["3"] takes longer because the system is trying to find
first CDATA-named property "1", fails on that and only then it gets
array element with index 3.


Thomas 'PointedEars' Lahn 11-12-2005 02:24 PM

Re: Object Hash vs. object Array preference
 
VK wrote:

> Lasse Reichstein Nielsen wrote:
>> Both Opera and Firefox seems to take extra time when the property is a
>> string containing a number literal, even when used on an object, not
>> an array. One can wonder why :)

>
> Was that a rhetorical question? :-)
> Naturally arr["3"] takes longer because the system is trying to find
> first CDATA-named property "1", fails on that and only then it gets
> array element with index 3.


CDATA is a data type specified in SGML/XML and used in DTDs for markup
languages. We are talking about a programming language specification
and its implementation, particularly ECMAScript 3 [1], subsection 11.2.1.

Will you learn how to quote?


PointedEars
___________
[1] <http://www.mozilla.org/js/language/E262-3.pdf>

VK 11-12-2005 03:29 PM

Re: Object Hash vs. object Array preference
 

> Thomas 'PointedEars' Lahn wrote:
> CDATA is a data type specified in SGML/XML and used in DTDs for markup
> languages. We are talking about a programming language specification
> and its implementation, particularly ECMAScript 3 [1], subsection 11.2.1.


?

JavaScript/JScript Object accepts CDATA literals as property name.

Array index is unsigned 32 bit value which allows you to hold
4294967295 array elements per array-that's one less than 32 bits can
hold: the remaining one is used for the length value.

So in case:
someObject["3"] = "foo";
interpreter checks first if the key can be converted into an integer in
the range 0,..., 4294967295
If it can then someObject is treated as array (if contextually
possible) and its element with index 3 gets value "foo".

If the key cannot be converted into integer or if such integer goes
outside of the 0,..., 4294967295 range then the value is used as new
property name:
someObject["-1.5"] = "foo"; // creates key "-1.5" with value "foo"
someObject["4294967296"] = "foo"; // creates key "4294967296" with
value "foo"

By explicetly serving a valid index value to a pre-declared array:
someArray[3] = "foo";
you free the interpreter from the unnecessary checks/transformations
and you get a noticeable productivity gain.

In this concern I don't care too much (actually I don't care at all) if
ECMA specs are saying something other, because this is how it does
really work on any browser I know of.

> Will you learn how to quote?


Well, sorry but I used to quote in the way one can see who am I
answering to (if there are several responses) and what am I answering
to:
Poster Name / Nickname wrote:
Quote
My answer
....
and I don't see any reason to change this habit unless some really
serious *logical* reasons will be provided (to fix it right away:
written rules are not one of them ;-)


Lasse Reichstein Nielsen 11-12-2005 05:13 PM

Re: Object Hash vs. object Array preference
 
"VK" <schools_ring@yahoo.com> writes:

> Rather elegant but requires Object<>Array back and forth casting which
> will swallow any productivity difference advantages between of them ?


There is no casting anywhere. In Javascript, arrays *are* objects, and
their numbered properties are just that: object properties. The only
"magic" in arrays are in the internal [[put]] method, which keeps
the "length" property in sync with the numbered properties. A literal
implementation of the ECMAScript specification of objects would use
the same [[get]] method for arrays and non-array objects.

> Wow: double speed gain on Array with FF. These are 1-10 seconds speed
> gain for application I guess - if you manage to stay within Array only.


Only if the application does nothing but array accesses and takes 2-20
seconds to run.

> IE seems rather indifferent but still just a bit quicklier.


That small a difference could easily be within the measuring
uncertainty.

>> Both Opera and Firefox seems to take extra time when the property is a
>> string containing a number literal, even when used on an object, not
>> an array. One can wonder why :)

>
> Was that a rhetorical question? :-)
> Naturally arr["3"] takes longer because the system is trying to find
> first CDATA-named property "1", fails on that and only then it gets
> array element with index 3.


That makes no sense. "CDATA" is an HTML type, not something that
exists in Javascript. If you just mean "string", then it's still
an interesting result, since the ECMAScript standard describes all
properties as strings, even array properties. The curious part was
that even on a non-array object, useing "3" as property name takes
longer than using "x", even though there is no reason to treat
numerals different from other property names.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Thomas 'PointedEars' Lahn 11-12-2005 05:32 PM

Re: Object Hash vs. object Array preference
 
VK wrote:

[Quotation corrected]

> Thomas 'PointedEars' Lahn wrote:
>> CDATA is a data type specified in SGML/XML and used in DTDs for markup
>> languages. We are talking about a programming language specification
>> and its implementation, particularly ECMAScript 3 [1], subsection 11.2.1.

>
> ?
>
> JavaScript/JScript Object accepts CDATA literals as property name.


Sorry, but this *is* utter nonsense indeed. You obviously have no idea
what CDATA is. Hint: there is not one reference to it in the ECMAScript
Specification, or any _JS language_ reference for that matter.

We are talking about built-in language objects here, not host DOM
objects where a reference to the CDATA type might be appropriate.

> Array index is unsigned 32 bit value


Yes.

> which allows you to hold 4294967295 array elements per array- that's one
> less than 32 bits can hold: the remaining one is used for the length
> value.


With this description, I am not sure we understand each other as it was
meant.

32 bits allow you to store 4294967296 different unsigned states. That is
4294967295 non-zero states plus the zero state. Which is why you could
_theoretically_ hold 4294967296 elements in one Array, where the minimum
element index is 0 and the maximum one is 4294967295. However, since
there has to be a _separate_ `length' property that also can only hold
an unsigned 32-bit integer (range from 0 to 2^32-1 = 4294967295) at the
maximum as well, only 4294967295 elements are allowed and thus only
4294967294 is allowed for maximum index.

> By explicetly serving a valid index value to a pre-declared array:
> someArray[3] = "foo";
> you free the interpreter from the unnecessary checks/transformations


No.

,-<http://www.mozilla.org/js/language/E262-3.pdf>
|
| [...]
| 11.2 Left-Hand-Side Expressions
|
| Syntax
|
| MemberExpression :
| PrimaryExpression
| FunctionExpression
| MemberExpression [ Expression ]
| MemberExpression . Identifier
| new MemberExpression Arguments
|
| [...]
| The production MemberExpression : MemberExpression [ Expression ] is
| evaluated as follows:
|
| 1. Evaluate MemberExpression.
| 2. Call GetValue(Result(1)).
| 3. Evaluate Expression.
| 4. Call GetValue(Result(3)).
| 5. Call ToObject(Result(2)).
| 6. Call ToString(Result(4)).
^^^^^^^^^^^^^^^^^^^^^^^^
| 7. Return a value of type Reference whose base object is Result(5) and
| whose property name is Result(6).

As you can see, if the implementation is standards compliant, all parameters
of the bracket property accessor are converted to String first. And *then*
follows

| 15.4 Array Objects
|
| Array objects give special treatment to a certain class of property names.
| A property name P (in the form of a string value) is an array index if and
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| only if ToString(ToUint32(P)) is equal to P and ToUint32(P) is not equal
| to 2^32?1.

So in terms of "saving the 'interpreter' work" it would be even more
efficient to always quote all parameters for the bracket property
accessor, thus saving it from type conversion in the abstract internal
ToString operator which is defined as follows:

| 9.8 ToString
|
| The operator ToString converts its argument to a value of type
| String according to the following table:
|
| Input Type Result
| ------------------------------------------------------------------
| Undefined "undefined"
| Null "null"
| Boolean If the argument is true, then the result is "true".
| If the argument is false, then the result is "false".
| Number See note below.
| String Return the input argument (no conversion)
| Object Apply the following steps:
| Call ToPrimitive(input argument, hint String).
| Call ToString(Result(1)).
| Return Result(2).
|
| 9.8.1 ToString Applied to the Number Type
|
| [too much to be quoted here, go read on that yourself]

You have not bothered to read the section of the specification I have
referred to and the other sections it is referring to. Again.

> and you get a noticeable productivity gain.


The reasons for this lie elsewhere, it is perhaps due to a not conforming
implementation.

>> Will you learn how to quote?

>
> Well, sorry but I used to quote in the way one can see who am I
> answering to (if there are several responses) and what am I answering
> to:
> Poster Name / Nickname wrote:
> Quote
> My answer
> ...
> and I don't see any reason to change this habit unless some really
> serious *logical* reasons will be provided (to fix it right away:
> written rules are not one of them ;-)


Your quotes are like this:

| > > User 1 wrote:
| > > [Text of User 1]
| .
| > User 2 wrote:
| > [Text of User 2]
|
| Your text

Expected (and, it appears to me, accepted) is:

| User 2 wrote:
| > User 1 wrote:
| > > [Text of User 1]
| >
| > [Text of User 2]
|
| Your text

Not only that the initial attribution line is to indicate who wrote what, to
allow quotes to be trimmed easily, the quotation character sequence is to
indicate the quotation level, to be able to assign quoted text to a person
easily.


HTH

PointedEars

Thomas 'PointedEars' Lahn 11-12-2005 05:42 PM

Re: Object Hash vs. object Array preference
 
Lasse Reichstein Nielsen wrote:

> "VK" <schools_ring@yahoo.com> writes:
>> Naturally arr["3"] takes longer because the system is trying to find
>> first CDATA-named property "1", fails on that and only then it gets
>> array element with index 3.

>
> That makes no sense. "CDATA" is an HTML type, not
> something that exists in Javascript.


Just to have my daily nitpick: it is an _SGML_ type :)


SCNR
PointedEars


All times are GMT. The time now is 04:09 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.