Ramine <ramine@1.1>: Feb 19 05:13PM -0800 Hello, StringTree was updated to version 1.1... I have optimized more my StringTree, what i have noticed is that i have to design it also like database, so i have noticed that i must add an "index" that is the "CreationOrder" to the Path, this new index that i have added using my very fast HashStringList have allowed to optimize more the search that is done by the method that is called FindFile() and FindFirstFile(), this new index that i have added have render the FindFile() method 27 times faster than my previous version that was not indexed on the "CreationOrder", so all in all StringTree version 1.1 is really very fast now, adding one million files is taking only 1.2 seconds on my benchmark on my Intel Quadcore Q6600 clocked at 2.4 Ghz, and the delete's methodes are also fast, and the search method with FindFile() and FindFirstFile() have become really really fast ! i have also stress tested StringTree and i think it is now stable, so all in all my new StringTree version 1.1 can be considered to have the same level of quality as a good industrial library. You can download my new StringTree version 1.1: https://sites.google.com/site/aminer68/stringtree Thank you, Amine Moulay Ramdane. |
Ramine <ramine@1.1>: Feb 19 05:26PM -0800 I correct some typos , please read again... Hello, StringTree was updated to version 1.1... I have optimized more my StringTree, what i have noticed is that i have to design it also like database, so i have noticed that i must add an "index" that is the "CreationOrder" to the Path, this new index that i have added using my very fast HashStringList has allowed to optimize more the search that is done by the method that is called FindFile() and FindFirstFile(), this new index that i have added have render the FindFile() method 27 times faster than my previous version that was not indexed on the "CreationOrder", so all in all StringTree version 1.1 is really very fast now, adding one million files is taking only 1.2 seconds on my benchmark on my Intel Quadcore Q6600 clocked at 2.4 Ghz, and the delete's methods are also fast, and the search methods with FindFile() and FindFirstFile() have become really really fast ! i have also stress tested StringTree and i think it is now stable, so all in all my new StringTree version 1.1 can be considered to have the same level of quality as a good industrial library. You can download my new StringTree version 1.1: https://sites.google.com/site/aminer68/stringtree Thank you, Amine Moulay Ramdane. |
Ramine <ramine@1.1>: Feb 19 01:11PM -0800 Hello, I have made a mistake on my previous benchmark benchmark for my StringTree, the previous benchmark was adding "two" millions files , but here is the benchmark for one million files using the new optimized version of my StringTree: I have redone a benchmark for my new StringTree , i have created 10 directories with 100000 files each, on my CPU Quadcore Q6600 clocked at 2.4 Ghz and it has scored only 1.2 seconds to create the one million files, so my new version is really very fast ! and i have done a FindFile() on a file's name that is contained in each directory that contains 100000 files and it has took 7100 microseconds, the delete's methods are also really very fast, so my StringTree library is really very fast and it can be considered to have the same level of quality as a good industrial library. You can download my StringTree from, the new version is still at 1.0: https://sites.google.com/site/aminer68/stringtree Thank you, Amine Moulay Ramdane. |
Ramine <ramine@1.1>: Feb 19 01:36PM -0800 On 2/19/2015 1:11 PM, Ramine wrote: > files, so my new version is really very fast ! and i have done a > FindFile() on a file's name that is contained in each directory that > contains 100000 files and it has took 7100 microseconds, the delete's The FindFile() on each of the 10 directories with 100000 files each that contain a file's name to search has took 500 microseconds, not 7100 microseconds, so StringTree is really very fast. |
Ramine <ramine@1.1>: Feb 19 12:04PM -0800 Hello, New approach to distributing computations could make multicore chips much faster Read more here: http://www.sciencedaily.com/releases/2015/02/150219101715.htm Amine Moulay Ramdane. |
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.programming.threads+unsubscribe@googlegroups.com. |
No comments:
Post a Comment