RE: Lists vs. Arrays vs. Structures
I've been happy with XML databases for this type of work. XML is naturally hierarchical, so XML databases handle that type of information well. I've been using Xindice quite a bit. You can read an article I wrote on Xindice here (http://www.devx.com/xml/article/9796). Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ 888-408-0900 x901 > -Original Message- > From: Dick Applebaum [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 09, 2002 10:00 PM > To: CF-Talk > Subject: Re: Lists vs. Arrays vs. Structures > > On Monday, December 9, 2002, at 05:53 PM, Matt Liotta wrote: > > > I highly recommend people look into a hierarchical engine for handle > > hierarchical information. > > > > > > Any suggestions, recommendations? > > TIA > > Dick > > ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
Re: Lists vs. Arrays vs. Structures
On Monday, December 9, 2002, at 05:53 PM, Matt Liotta wrote: > I highly recommend people look into a hierarchical engine for handle > hierarchical information. > > Any suggestions, recommendations? TIA Dick ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting.
RE: Lists vs. Arrays vs. Structures
Nested sets tends to be one of the better ways to handle hierarchical information in a relational engine, but still generally sucks in comparison to a hierarchical engine. The hash string method that I briefly describe below tends to be easier to understand than nested sets and has the added benefit of being more scalable. In fact, we used a similar method when I was at DevX to handle our multi-dimensional taxonomy that handled hundreds of thousands nodes. I highly recommend people look into a hierarchical engine for handle hierarchical information. Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ 888-408-0900 x901 > -Original Message- > From: Jeffry Houser [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 09, 2002 7:59 PM > To: CF-Talk > Subject: RE: Lists vs. Arrays vs. Structures > > As an aside to this conversation.. > > Ya'll may want to take a look at this thread > <http://www.sitepointforums.com/showthread.php?s=&threadid=84833>. > I have not been following it religiously, but it does talk about > building > a discussion room / forum. It touch base on self-referencing tables ( as > described below ) and a different method called nested sets, which they go > into in the thread (with links to resources). > > > At 03:30 PM 12/9/2002 -0500, you wrote: > >If I understand you correctly, you are representing a hierarchical > >relationship in a tabular manner. If there is another way you can store > >this information I would suggest it highly as there are many data > >structures much better suited for storage of hierarchical information. > >For example, a tree would give you O(log N) vs. your current O(N) > >performance. As you can see, if N is large it makes a big difference. > > > >Now then, assuming you are stuck on your tabular data structure I would > >suggest some changes to it. Right now you have the following. > > > >itemidparentidname > >10root > >211st child of root > >321st sub child > >422nd sub child > >512nd child of root > >651st child of 2nd > > > >Instead of relating a child to its parent via a primary key, I would > >suggest creating a hash string to represent the relationship, which > >might look like the following. > > > >itemId hashname > >1 001 root > >2 001002 1st child of root > >3 001002003 1st sub child > >4 001002004 2nd sub child > >5 001005 2nd child of root > >6 001005006 1st child of 2nd > > > >Above I have used a simple hash formula, which represents the itemId > >using a 3 digit fixed notation. I then create a hash string for each > >item by appending the item's hash to that of its parent's. This allows > >you to just sort the whole table based on a single column and everything > >is done for you. > > > >The above has formula is only an example and is limited to 999 unique > >items. You would need to create a hash formula best suited for the > >number of unique items you need to support. However, resist the > >temptation to make individual item's hash too long as deeply nest items > >would have very long strings. > > > >Matt Liotta > >President & CEO > >Montara Software, Inc. > >http://www.montarasoftware.com/ > >888-408-0900 x901 > > > > > -Original Message- > > > From: Michael Dinowitz [mailto:[EMAIL PROTECTED]] > > > Sent: Monday, December 09, 2002 3:08 PM > > > To: CF-Talk > > > Subject: Re: Lists vs. Arrays vs. Structures > > > > > > You can see the code here: > > > http://www.houseoffusion.com/_library/maketree.txt > > > Your example will fail as there can be more than one item with the > >same > > > 'parent', which is what we're looking for. No matter what, we have to > >do a > > > search and the list search functions seem to be the fastest of the > > > searches > > > around, even though the list items have to be parsed. > > > > > > For those wondering what's going on, when dealing with a query that > >has to > > > be > > > turned into a tree, you have to first find the 'root' item, then all > >of > > > its > > > children, then the next root item, etc. > > > > > > itemidparentidname > > > 10
RE: Lists vs. Arrays vs. Structures
As an aside to this conversation.. Ya'll may want to take a look at this thread <http://www.sitepointforums.com/showthread.php?s=&threadid=84833>. I have not been following it religiously, but it does talk about building a discussion room / forum. It touch base on self-referencing tables ( as described below ) and a different method called nested sets, which they go into in the thread (with links to resources). At 03:30 PM 12/9/2002 -0500, you wrote: >If I understand you correctly, you are representing a hierarchical >relationship in a tabular manner. If there is another way you can store >this information I would suggest it highly as there are many data >structures much better suited for storage of hierarchical information. >For example, a tree would give you O(log N) vs. your current O(N) >performance. As you can see, if N is large it makes a big difference. > >Now then, assuming you are stuck on your tabular data structure I would >suggest some changes to it. Right now you have the following. > >itemidparentidname >10root >211st child of root >321st sub child >422nd sub child >512nd child of root >651st child of 2nd > >Instead of relating a child to its parent via a primary key, I would >suggest creating a hash string to represent the relationship, which >might look like the following. > >itemId hashname >1 001 root >2 001002 1st child of root >3 001002003 1st sub child >4 001002004 2nd sub child >5 001005 2nd child of root >6 001005006 1st child of 2nd > >Above I have used a simple hash formula, which represents the itemId >using a 3 digit fixed notation. I then create a hash string for each >item by appending the item's hash to that of its parent's. This allows >you to just sort the whole table based on a single column and everything >is done for you. > >The above has formula is only an example and is limited to 999 unique >items. You would need to create a hash formula best suited for the >number of unique items you need to support. However, resist the >temptation to make individual item's hash too long as deeply nest items >would have very long strings. > >Matt Liotta >President & CEO >Montara Software, Inc. >http://www.montarasoftware.com/ >888-408-0900 x901 > > > -Original Message- > > From: Michael Dinowitz [mailto:[EMAIL PROTECTED]] > > Sent: Monday, December 09, 2002 3:08 PM > > To: CF-Talk > > Subject: Re: Lists vs. Arrays vs. Structures > > > > You can see the code here: > > http://www.houseoffusion.com/_library/maketree.txt > > Your example will fail as there can be more than one item with the >same > > 'parent', which is what we're looking for. No matter what, we have to >do a > > search and the list search functions seem to be the fastest of the > > searches > > around, even though the list items have to be parsed. > > > > For those wondering what's going on, when dealing with a query that >has to > > be > > turned into a tree, you have to first find the 'root' item, then all >of > > its > > children, then the next root item, etc. > > > > itemidparentidname > > 10 root > > 21 1st child of root > > 32 1st sub child > > 42 2nd sub child > > 51 2nd child of root > > 65 1st child of 2nd > > We would have to first look at root and get its children. Item 2 is >its > > first > > child. Does item 2 have any children? If so, we get those children on > > down. When > > item 2 or it's children are finished, we go onto the next chold of the > > root. > > That is item 5. We do the same thing for 5, getting all of its >children. > > > > > Michael Dinowitz wrote: > > > > I think that a new array search function might be in order here. > > Something > > to > > > > look through an array for a value and return its index. > > > > > > > >>I'm not sure what you are really trying to accomplish here. > > > > > > I agree with matt, are you working on the maketree tag in cf? lets >talk > > > examples... > > > > > > do you modify the array, ( ie inserting or deleting array members >other > > > than from the end?) if no
Re: Lists vs. Arrays vs. Structures
Michael Dinowitz wrote: > You can see the code here: > http://www.houseoffusion.com/_library/maketree.txt > Your example will fail as there can be more than one item with the same > 'parent', which is what we're looking for. No matter what, we have to do a > search and the list search functions seem to be the fastest of the searches > around, even though the list items have to be parsed. ok gotta run, times short in a second but off the top of my head i would loop over the query first and then make each parentid a structure containing the items item_struct=StructNew(); if (NOT structkeyExists(item_struct,qry_items.parentId) ) item_struct[qry_items.parentId]=structnew(); item_struct[qry_items.parentId][qry_items.itemid]=qry_items.currentrow; now everything is grouped by parentid now we know that the items in item_struct[0] are the first level, you could then loop over the collection if ( structkeyExists(item_struct,child) ) // yes there are children add to the to be processed list else // no it's just a member with no children and so on... sorry time ran out z ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
RE: Lists vs. Arrays vs. Structures
If I understand you correctly, you are representing a hierarchical relationship in a tabular manner. If there is another way you can store this information I would suggest it highly as there are many data structures much better suited for storage of hierarchical information. For example, a tree would give you O(log N) vs. your current O(N) performance. As you can see, if N is large it makes a big difference. Now then, assuming you are stuck on your tabular data structure I would suggest some changes to it. Right now you have the following. itemidparentidname 10root 211st child of root 321st sub child 422nd sub child 512nd child of root 651st child of 2nd Instead of relating a child to its parent via a primary key, I would suggest creating a hash string to represent the relationship, which might look like the following. itemId hashname 1 001 root 2 001002 1st child of root 3 001002003 1st sub child 4 001002004 2nd sub child 5 001005 2nd child of root 6 001005006 1st child of 2nd Above I have used a simple hash formula, which represents the itemId using a 3 digit fixed notation. I then create a hash string for each item by appending the item's hash to that of its parent's. This allows you to just sort the whole table based on a single column and everything is done for you. The above has formula is only an example and is limited to 999 unique items. You would need to create a hash formula best suited for the number of unique items you need to support. However, resist the temptation to make individual item's hash too long as deeply nest items would have very long strings. Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ 888-408-0900 x901 > -Original Message- > From: Michael Dinowitz [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 09, 2002 3:08 PM > To: CF-Talk > Subject: Re: Lists vs. Arrays vs. Structures > > You can see the code here: > http://www.houseoffusion.com/_library/maketree.txt > Your example will fail as there can be more than one item with the same > 'parent', which is what we're looking for. No matter what, we have to do a > search and the list search functions seem to be the fastest of the > searches > around, even though the list items have to be parsed. > > For those wondering what's going on, when dealing with a query that has to > be > turned into a tree, you have to first find the 'root' item, then all of > its > children, then the next root item, etc. > > itemidparentidname > 10 root > 21 1st child of root > 32 1st sub child > 42 2nd sub child > 51 2nd child of root > 65 1st child of 2nd > We would have to first look at root and get its children. Item 2 is its > first > child. Does item 2 have any children? If so, we get those children on > down. When > item 2 or it's children are finished, we go onto the next chold of the > root. > That is item 5. We do the same thing for 5, getting all of its children. > > > Michael Dinowitz wrote: > > > I think that a new array search function might be in order here. > Something > to > > > look through an array for a value and return its index. > > > > > >>I'm not sure what you are really trying to accomplish here. > > > > I agree with matt, are you working on the maketree tag in cf? lets talk > > examples... > > > > do you modify the array, ( ie inserting or deleting array members other > > than from the end?) if not then u could index the array using structures > > > > > > item_array=ArrayNew(1); > > item_struct=StructNew(); > > > > > > > > > > x=arraylen(item_array); > > item_array[x]=qry_item.item; > > item_struct[qry_item.item]=x; > > > > > > > > find where dog is in the array = item_struct["dog"] or item_struct.dog > > > > this method is so fast scaling the dataset makes almost no difference in > > speed > > > > now you can always find the position of x in the array using the struct, > > this of course doesn't handle very well adding elements to the aray > > > > ideally I would try to eliminate arrays all together... esp when u > > consider that have 2 values in a struct, the key and the value > > > > z > > > > > ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm
Re: Lists vs. Arrays vs. Structures
You can see the code here: http://www.houseoffusion.com/_library/maketree.txt Your example will fail as there can be more than one item with the same 'parent', which is what we're looking for. No matter what, we have to do a search and the list search functions seem to be the fastest of the searches around, even though the list items have to be parsed. For those wondering what's going on, when dealing with a query that has to be turned into a tree, you have to first find the 'root' item, then all of its children, then the next root item, etc. itemidparentidname 10 root 21 1st child of root 32 1st sub child 42 2nd sub child 51 2nd child of root 65 1st child of 2nd We would have to first look at root and get its children. Item 2 is its first child. Does item 2 have any children? If so, we get those children on down. When item 2 or it's children are finished, we go onto the next chold of the root. That is item 5. We do the same thing for 5, getting all of its children. > Michael Dinowitz wrote: > > I think that a new array search function might be in order here. Something to > > look through an array for a value and return its index. > > > >>I'm not sure what you are really trying to accomplish here. > > I agree with matt, are you working on the maketree tag in cf? lets talk > examples... > > do you modify the array, ( ie inserting or deleting array members other > than from the end?) if not then u could index the array using structures > > > item_array=ArrayNew(1); > item_struct=StructNew(); > > > > > x=arraylen(item_array); > item_array[x]=qry_item.item; > item_struct[qry_item.item]=x; > > > > find where dog is in the array = item_struct["dog"] or item_struct.dog > > this method is so fast scaling the dataset makes almost no difference in > speed > > now you can always find the position of x in the array using the struct, > this of course doesn't handle very well adding elements to the aray > > ideally I would try to eliminate arrays all together... esp when u > consider that have 2 values in a struct, the key and the value > > z > > ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting.
Re: Lists vs. Arrays vs. Structures
Michael Dinowitz wrote: > I think that a new array search function might be in order here. Something to > look through an array for a value and return its index. > >>I'm not sure what you are really trying to accomplish here. I agree with matt, are you working on the maketree tag in cf? lets talk examples... do you modify the array, ( ie inserting or deleting array members other than from the end?) if not then u could index the array using structures item_array=ArrayNew(1); item_struct=StructNew(); x=arraylen(item_array); item_array[x]=qry_item.item; item_struct[qry_item.item]=x; find where dog is in the array = item_struct["dog"] or item_struct.dog this method is so fast scaling the dataset makes almost no difference in speed now you can always find the position of x in the array using the struct, this of course doesn't handle very well adding elements to the aray ideally I would try to eliminate arrays all together... esp when u consider that have 2 values in a struct, the key and the value z ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm
Re: Lists vs. Arrays vs. Structures
I think your missing the point of what a list is in ColdFusion in relationship to what an array or structure is. A list is simply a string that will have to be parsed by CF to be seen as a collection of data. After its been parsed it can then be searched. That parsing, especially when done in Java is what the true question is. Will a structure, which already has the individual items separated into storage areas operate faster than a string which has to do more work? I'd expect the structure to be faster, but its not. I think that a new array search function might be in order here. Something to look through an array for a value and return its index. > I'm not sure what you are really trying to accomplish here. It is a well > known fact that the data structure of choice to do a linear search > against is a list. Any linear search is going to be O(N) plus whatever > overhead each operation incurs and a list has the lowest overhead per > operation. You only want to use arrays or maps (structs) when you > require random access to the data. Arrays tend to be a good way of > representing different types of trees, which generally are the best data > structures to search for a value against. For example, balanced trees > can generally offer O(log N) worst case. Finally, maps are generally > meant to be when you are dealing with known keys. If you know the key, a > map is O(1) for retrieving the value, which is always going to be better > than any other data structure. However, if you attempt to search a map > without knowing a key then you are really no better off than searching a > list. > > See http://www.cs.fiu.edu/~weiss/ for more information on algorithms and > data structures. > > Matt Liotta > President & CEO > Montara Software, Inc. > http://www.montarasoftware.com/ > 888-408-0900 x901 > > > -Original Message- > > From: Michael Dinowitz [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, December 04, 2002 12:06 AM > > To: CF-Talk > > Subject: Lists vs. Arrays vs. Structures > > > > I'm rewriting my CFMakeTree tag in order to make it tighter and work > in > > CFMX > > better. One of the assumptions I had was that Lists would be > problematic > > in > > comparison to Arrays or Structs. My first test was to find a value in > one > > of > > these data collections. > > For Lists I used ListFindNoCase. For Arrays, I looped over the array > to > > find the > > value and for Structs I used StructFindValue(). I ran each test in a > 1000 > > iteration loop to see if anything showed up. On the whole, Arrays took > the > > longest, which is to be expected as they had to loop (no native > arrayfind > > function). Structures took less then 10% of the array time to search > and > > lists > > took 1/3 of the struct time. The data set was 0-9a-z written out in > full > > and the > > item searched for was the z. > > So the results are basically that lists are easier to search than > either > > structures or arrays. > > As a side note, I tried using a query of queries and it was much, much > > slower. > > > > The second experiment was to loop over each data collection. In this, > we > > see > > much different results. > > Arrays were fastest. Lists were anywhere from about as fast as an > array to > > twice > > as slow. Structures tended to be on par with lists, but sometimes > slower. > > On the whole, unless you see a need to, I'd stick with using lists in > > CFMX. I > > have heard of people who have seen some major slowdowns due to lists > and > > I'd > > love to hear the specifics. > > > > Michael Dinowitz > > Master of the House of Fusion > > http://www.houseoffusion.com > > > > > ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com
RE: Lists vs. Arrays vs. Structures
I'm not sure what you are really trying to accomplish here. It is a well known fact that the data structure of choice to do a linear search against is a list. Any linear search is going to be O(N) plus whatever overhead each operation incurs and a list has the lowest overhead per operation. You only want to use arrays or maps (structs) when you require random access to the data. Arrays tend to be a good way of representing different types of trees, which generally are the best data structures to search for a value against. For example, balanced trees can generally offer O(log N) worst case. Finally, maps are generally meant to be when you are dealing with known keys. If you know the key, a map is O(1) for retrieving the value, which is always going to be better than any other data structure. However, if you attempt to search a map without knowing a key then you are really no better off than searching a list. See http://www.cs.fiu.edu/~weiss/ for more information on algorithms and data structures. Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ 888-408-0900 x901 > -Original Message- > From: Michael Dinowitz [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 04, 2002 12:06 AM > To: CF-Talk > Subject: Lists vs. Arrays vs. Structures > > I'm rewriting my CFMakeTree tag in order to make it tighter and work in > CFMX > better. One of the assumptions I had was that Lists would be problematic > in > comparison to Arrays or Structs. My first test was to find a value in one > of > these data collections. > For Lists I used ListFindNoCase. For Arrays, I looped over the array to > find the > value and for Structs I used StructFindValue(). I ran each test in a 1000 > iteration loop to see if anything showed up. On the whole, Arrays took the > longest, which is to be expected as they had to loop (no native arrayfind > function). Structures took less then 10% of the array time to search and > lists > took 1/3 of the struct time. The data set was 0-9a-z written out in full > and the > item searched for was the z. > So the results are basically that lists are easier to search than either > structures or arrays. > As a side note, I tried using a query of queries and it was much, much > slower. > > The second experiment was to loop over each data collection. In this, we > see > much different results. > Arrays were fastest. Lists were anywhere from about as fast as an array to > twice > as slow. Structures tended to be on par with lists, but sometimes slower. > On the whole, unless you see a need to, I'd stick with using lists in > CFMX. I > have heard of people who have seen some major slowdowns due to lists and > I'd > love to hear the specifics. > > Michael Dinowitz > Master of the House of Fusion > http://www.houseoffusion.com > > ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com
Re: Lists vs. Arrays vs. Structures
Michael Dinowitz wrote: >>isn't structkeyexists better than structfindvalue? as our jedi friend >>says, after not evalutating, cflocking I think that's his next biggest tip > > It's better if you just want to know if the value exists. I need to know where > it exists. > > >>my experience is that structures are always *way* faster than lists or >>arrays.. basically because structures are key indexed > > Do you have any code to show this? I'm not seeing *way* faster. ok, it depends on what we are talking about, I would usually use a single depth structure, ie kinda of denormalising the data structure... to provide an indexing function, that returns references, know what i mean? structfindvalue isn't going to be using hashing in cf is it? ie a full table scan... my approach is only to work via struct keys, as they are hash indexed anyway, throw some of your code up and we can explore the ideas... z ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
RE: Lists vs. Arrays vs. Structures
> > isn't structkeyexists better than structfindvalue? as our > jedi friend > > says, after not evalutating, cflocking I think that's his > next biggest > > tip > It's better if you just want to know if the value exists. I > need to know where it exists. Michael is correct here. StructFindValue allows you to search into inside an arbitrarily deep structure and find a value. It and it's cousin, StructFindKey, or functions that are pretty powerful, but I almost never see anyone use. === Raymond Camden, ColdFusion Jedi Master for Mindseye, Inc Email: [EMAIL PROTECTED] WWW : www.camdenfamily.com/morpheus Yahoo IM : morpheus "My ally is the Force, and a powerful ally it is." - Yoda ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
Re: Lists vs. Arrays vs. Structures
Thanks for the note. I'll test list sorting and the like next. > Michael Dinowitz wrote: > > > > On the whole, unless you see a need to, I'd stick with using lists in CFMX. I > > have heard of people who have seen some major slowdowns due to lists and I'd > > love to hear the specifics. > > Anything that changes a long list (or string for that matter) is slow. > It is really related to changes, all the search functions are fast. > > Jochem > > ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
Re: Lists vs. Arrays vs. Structures
Michael Dinowitz wrote: > > On the whole, unless you see a need to, I'd stick with using lists in CFMX. I > have heard of people who have seen some major slowdowns due to lists and I'd > love to hear the specifics. Anything that changes a long list (or string for that matter) is slow. It is really related to changes, all the search functions are fast. Jochem ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
Re: Lists vs. Arrays vs. Structures
> isn't structkeyexists better than structfindvalue? as our jedi friend > says, after not evalutating, cflocking I think that's his next biggest tip It's better if you just want to know if the value exists. I need to know where it exists. > my experience is that structures are always *way* faster than lists or > arrays.. basically because structures are key indexed Do you have any code to show this? I'm not seeing *way* faster. ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm
Re: Lists vs. Arrays vs. Structures
Michael Dinowitz wrote: > I'm rewriting my CFMakeTree tag in order to make it tighter and work in CFMX > better. One of the assumptions I had was that Lists would be problematic in > comparison to Arrays or Structs. My first test was to find a value in one of > these data collections. > For Lists I used ListFindNoCase. For Arrays, I looped over the array to find the > value and for Structs I used StructFindValue(). I ran each test in a 1000 isn't structkeyexists better than structfindvalue? as our jedi friend says, after not evalutating, cflocking I think that's his next biggest tip my experience is that structures are always *way* faster than lists or arrays.. basically because structures are key indexed z ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting.
Lists vs. Arrays vs. Structures
I'm rewriting my CFMakeTree tag in order to make it tighter and work in CFMX better. One of the assumptions I had was that Lists would be problematic in comparison to Arrays or Structs. My first test was to find a value in one of these data collections. For Lists I used ListFindNoCase. For Arrays, I looped over the array to find the value and for Structs I used StructFindValue(). I ran each test in a 1000 iteration loop to see if anything showed up. On the whole, Arrays took the longest, which is to be expected as they had to loop (no native arrayfind function). Structures took less then 10% of the array time to search and lists took 1/3 of the struct time. The data set was 0-9a-z written out in full and the item searched for was the z. So the results are basically that lists are easier to search than either structures or arrays. As a side note, I tried using a query of queries and it was much, much slower. The second experiment was to loop over each data collection. In this, we see much different results. Arrays were fastest. Lists were anywhere from about as fast as an array to twice as slow. Structures tended to be on par with lists, but sometimes slower. On the whole, unless you see a need to, I'd stick with using lists in CFMX. I have heard of people who have seen some major slowdowns due to lists and I'd love to hear the specifics. Michael Dinowitz Master of the House of Fusion http://www.houseoffusion.com ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
