Ahh okay -- some of the rules for variable naming changed in MX and I haven't really played with it much... like I know now you can do stuff like #1 + 1# in a cfoutput and get 2 which prior to MX produced an error... Personally I don't like seeing #1 + 1# or similar ... I just think it looks sloppy and would rather see #int(1 + 1)# or something similar, but that's my own hangup. :) And I'm liable to use methods that also work on CF5 whenever possible just in case, but again, that's me.
> No, you can do stTest.2003.10.15 = 'fred' and have > structure of > structures. You do not need to put the numbers in > brackets or quotes. > That would be an interesting way to store data for dates. > -----Original Message----- > From: S.Isaac Dealey [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 28, 2003 6:36 PM > To: [EMAIL PROTECTED] > Subject: RE: structures vs arrays > Yes, although if you used hard-coded numbers you'd have to > quote them, and otherwise you'll have to use array > notation > anyway, although I suspect it'll still work with array > notation... but I don't think you can write in > stTest.1098... I think it has to be stTest[x] or > stTest["1098"] ... but then that's conjecture, I haven't > tried it in mx recently... > MX probably doesn't need to use space for the variable for > an unassigned array cell... however... it does need to > allocate space for a pointer to that value... > in memory, the array looks kinda like this: > m[l4][p1][p2][p3][p4] > with l4 representing the length of the array and each p# > entry being a pointer to a variable for that cell... so > when > you go grab a given cell the JVM just adds the integer > index > to the memory address for the array to get the memory > address for the pointer for that value, which is generally > more efficient than the hash for a structure. If the cell > is > unassigned, the pointer is null... but it still requires > that memory for the pointer. At least -- that's the > impression I've been under... I could be wrong. > Isaac >> My colleague claims there's no memory usage for empty >> array cells, but I >> disagree. With CFMX you do not have to declare your sub >> structures with >> structnew(). CFMX assumes it's a structure and creates >> it >> as such. So >> you can do stTest.1098.1.3 and have a structure of >> structure without >> declaring the sub structures. >> Thanks >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> Sent: Thursday, August 28, 2003 11:22 AM >> To: [EMAIL PROTECTED] >> Subject: RE: structures vs arrays >> It may or may not be more efficient to do this in a >> structure ... I >> would guess that it probably won't ever be less efficient >> to do it with >> a structure if your array is always going to be tens of >> thousands of >> entries... I don't know personally if CF stores a value >> for each empty >> entry in the array -- I know it has to at least store the >> length of the >> array somewhere, but it may or may not store an empty >> string value for >> each empty element. I suspect it doesn't. Though afaik it >> still has to >> allocate memory in order to determine if there is a value >> for a given >> item in the array (if no value was set, the memory >> address >> reads null >> which the CF Server then returns as an empty string). >> Although I would probably use a structure of structures >> (which will >> sound/seem strange because the syntax will in most cases >> be the same as >> for an array), rather than a single structure... i.e. >> stTest = structnew(); >> stTest["1098"] = structnew(); >> stTest["1098"]["1"] = structnew(); >> stTest["1098"]["1"]["3"] = "5/15/2003"; >> Although because in most cases you won't be hard-coding >> the values, the >> syntax will be identical to a 3-d array, i.e. >> stText[x][y][z]; >> My reason for using a structure has more to do with the >> code than with >> the efficiency -- I suspect it'd be a close call and >> you'd >> have to >> actually load-test it (if only in a rudimentary way) to >> know which is >> more efficient. I don't personally like seeing all those >> empty cells, >> which is why I prefer the structure approach. >> ike >> ------ Original Message ------ >> From: Schreck, Tom <[EMAIL PROTECTED]> >> To: <[EMAIL PROTECTED]> >> Sent: Aug 28, 2003 10:55 AM >> Subject: RE: structures vs arrays >>>Here's an example: >>> >>><cfscript> >>> arTest = arraynew(3); >>> arTest[1098][1][3] = '5/15/2003'; >>> arTest[2034][3][6]= '7/15/2003'; >>> arTest[156][2][5]= '4/15/2003'; >>></cfscript> >>> >>><cfoutput> >>>array length: #arraylen(arTest)# >>></cfoutput> >>> >>><cfdump var="#arTest[156][2][5]#"> >>><cfdump var="#arTest[1098][1][3]#"> >>><cfdump var="#arTest#"> >>> >>> >>>If you look at the dump of arTest, you will see thousand >>>of empty array >>>cells. Does CF store these empty array cells in memory? >>>I'm having an >>>interesting discussion with a colleague as to why this is >>>a bad idea >>>because it's not very efficient. Keep in mind this array >>>will be 10s >> of >>>thousands of entries long. >>> >>>Would a structure containing the concatenated key be more >>>efficient? >>> >>><cfscript> >>> stTest = structnew(); >>> stTest['1098_1_3'] = '5/15/2003'; >>> stTest['2034_3_6'] = '7/15/2003'; >>> stTest['156_2_5'] = '4/15/2003'; >>></cfscript> >>> >>><cfdump var="#stTest#"> >>> >>> >>> >>>Thanks - >>> >>>Tom Schreck >>>817-252-4900 >>>[EMAIL PROTECTED] >>> >>>I have not failed. I've found 10,000 ways that won't >>>work. >>> >>>- Thomas Edison >>> >>> >>>-----Original Message----- >>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>>Sent: Thursday, August 28, 2003 10:53 AM >>>To: [EMAIL PROTECTED] >>>Subject: RE: structures vs arrays >>> >>>Or extremely high traffic on a given page yea... Most of >>>the time I >>>don't generally put a lot of thought into which is more >>>(or less) >>>efficient -- I write what's easiest to implement and >>>easiest to change >>>or expand on later. When I have a project that's having a >>>problem >>>handling the load (which is fairly uncommon), then I look >>>for tweaks to >>>make it more efficient. >>> >>> >>>------ Original Message ------ >>>From: Dan Blackman <[EMAIL PROTECTED]> >>>To: <[EMAIL PROTECTED]> >>>Sent: Aug 28, 2003 09:56 AM >>>Subject: RE: structures vs arrays >>> >>>>It's also negligible unless you are working with >>>>hundereds of >> thousands >>>>of rows in MHO. You are not going to see the difference >>>>until you are >>>>hitting a sizable recordset... >>>> >>>>My 2 c >>>> >>>>-----Original Message----- >>>>From: [EMAIL PROTECTED] >>>>[mailto:[EMAIL PROTECTED] On >>>>Behalf Of S.Isaac Dealey >>>>Sent: Thursday, August 28, 2003 9:41 AM >>>>To: [EMAIL PROTECTED] >>>>Subject: Re: structures vs arrays >>>> >>>> >>>>> Which one is more efficient at retrieving data: >>>>> structure >>>>> or an array? >>>> >>>>Depends what you're doing with it... >>>> >>>>A structure is faster at finding a key than it is to >>>>find >>>>a given >>>string >>>>within an array... i.e. >>>> >>>>idx = structkeyexists(mystruct,"blah") >>>> >>>>vs. something like this: >>>> >>>>idx = listfind(arraytolist(myarray),"blah") >>>> >>>>or worse >>>> >>>>idx = 0; >>>>for (x = 1; x lte arraylen(myarray); x = x + 1) { >>>> if (myarray[x] is "blah") { idx = x; break; } >>>>} >>>> >>>>I believe arrays are slightly faster when looping over >>>>them, i.e. >>>> >>>><cfloop index="x" from="1" >>>>to="#arraylen(myarray)#"></cfloop> >>>> >>>>vs. >>>> >>>><cfloop item="x" collection="#mystruct#"></cfloop> >>>> >>>>and I'm pretty sure getting a single value from an array >>>> >>>>myarray[3] >>>> >>>>is faster than getting a single value from a structure >>>> >>>>mystruct["blue"] >>>> >>>>I hope that's helpful. :) >>>> >>>>s. isaac dealey 972-490-6624 >>>> >>>>team macromedia volunteer >>>>http://www.macromedia.com/go/team >>>> >>>>chief architect, tapestry cms >>>>http://products.turnkey.to >>>> >>>>onTap is open source >>>>http://www.turnkey.to/ontap >>>> >>>> >>>>----------------------------------------------- >>>>To post, send email to [EMAIL PROTECTED] >>>>To unsubscribe: >>>> Send UNSUBSCRIBE to [EMAIL PROTECTED] >>>>To subscribe / unsubscribe: http://www.dfwcfug.org >>>> >>>>----------------------------------------------- >>>>To post, send email to [EMAIL PROTECTED] >>>>To unsubscribe: >>>> Send UNSUBSCRIBE to [EMAIL PROTECTED] >>>>To subscribe / unsubscribe: http://www.dfwcfug.org >>> >>> >>> >>> >>>----------------------------------------------- >>>To post, send email to [EMAIL PROTECTED] >>>To unsubscribe: >>> Send UNSUBSCRIBE to [EMAIL PROTECTED] >>>To subscribe / unsubscribe: http://www.dfwcfug.org >>> >>>----------------------------------------------- >>>To post, send email to [EMAIL PROTECTED] >>>To unsubscribe: >>> Send UNSUBSCRIBE to [EMAIL PROTECTED] >>>To subscribe / unsubscribe: http://www.dfwcfug.org >> ----------------------------------------------- >> To post, send email to [EMAIL PROTECTED] >> To unsubscribe: >> Send UNSUBSCRIBE to [EMAIL PROTECTED] >> To subscribe / unsubscribe: http://www.dfwcfug.org >> ----------------------------------------------- >> To post, send email to [EMAIL PROTECTED] >> To unsubscribe: >> Send UNSUBSCRIBE to [EMAIL PROTECTED] >> To subscribe / unsubscribe: http://www.dfwcfug.org > s. isaac dealey 972-490-6624 > team macromedia volunteer > http://www.macromedia.com/go/team > chief architect, tapestry cms http://products.turnkey.to > onTap is open source http://www.turnkey.to/ontap > ----------------------------------------------- > To post, send email to [EMAIL PROTECTED] > To unsubscribe: > Send UNSUBSCRIBE to [EMAIL PROTECTED] > To subscribe / unsubscribe: http://www.dfwcfug.org > ----------------------------------------------- > To post, send email to [EMAIL PROTECTED] > To unsubscribe: > Send UNSUBSCRIBE to [EMAIL PROTECTED] > To subscribe / unsubscribe: http://www.dfwcfug.org s. isaac dealey 972-490-6624 team macromedia volunteer http://www.macromedia.com/go/team chief architect, tapestry cms http://products.turnkey.to onTap is open source http://www.turnkey.to/ontap ----------------------------------------------- To post, send email to [EMAIL PROTECTED] To unsubscribe: Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe / unsubscribe: http://www.dfwcfug.org
