Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Hash Table performance

Hi

Just read about the hash table.
Are there any gut feelings about performance with this utility, say as compared to RTP65.
I currently have an RTP65 issue, and thought I might like to give the SRP one a go.

Also... is it OK to create a hash table on application start, and have it sitting there available for use during the entire time the application is running, and just clear on close.

Colin

Comments

  • Colin,

    I didn't write the code for this (that was Kevin's job) but I have put it to very good use. In fact, it is now entrenched within SRP FrameWorks having replaced our common use of User-Defined Properties to store data in memory for later retrieval. So to your last question, yes, you can create a hash table upon application start and use it as needed throughout the life of the application. We use it so much that I created a service wrapper for it. This creates a bit more overhead (thus it cuts down on performance when used in a tight loop over thousands of iterations) but the convenience trade-off is usually worth it. Of course, if performance is critical I can just call the SRP HashTable directly.

    In terms of head-to-head performance I actually performed several bench-marking tests on my own. This bench-mark test took into account several things:
    • RTP65
    • SRP HashTable
    • RTI_HashTable2
    • User-Defined Properties
    • Basic+ Locate
    • SRP List
    • SRP FastArray

    The main lesson learned is to use the right tool for the right job. Hash Tables are great, but our in-memory List and Array utilities can be better suited to the task. It depends on what you are using it for.

    I also wanted to evaluate real-world scenarios as much as possible so my test pulled down 35K records from a LH table and populate the three in-memory hash tables. I then read the data from these in-memory hash tables.

    The general rule was that SRP HashTable was faster in real world (or random access) tests. RTP65 was only faster if the same data was being read over and over. We suspect this is due to caching. Thus, the random access tests were more informative. RTI_HashTable2 was surprisingly slow. We found better performance just going straight to the LH database table.
Sign In or Register to comment.