When I originally wrote the tagname handling code I put all of the tags in a dynamically allocated array that I intended to grow as needed with calls to realloc(). I also have similar intentions with the database itself. The original size of these arrays as well as the amount that they grow are based on #define'd in dax/tagbase.h.
Before today the two calls to grow the tagname array and the database simply returned errors. I was testing other things at the time and this was sufficient. I started playing with the actual reallocation of these arrays this weekend. The actual reallocation was not that difficult but I started getting some pretty ugly behavior out of the tag adding functions. The bug that I finally found was in the part of the tag adding code where it makes a hole in the tagname array to insert a new tag in the middle of the array. (The tagname array must always be sorted by database handle). I wasn't dealing with the very last item in the array correctly. If the last tag added to the array, before it had to grow, was inserted in the middle instead of going on the end, the whole thing went haywire. It was a computer science 101 mistake but it was one that has existed in the code for many moons but didn't show itself until I started growing the array of tagnames past the original allocation.
During all of this I wrote some tests for the daxtest module that would add a certain number of random tags as well as test the resulting tag list for improper sorting and/or database overlap. Once my tests and the tag adding functions seemed to work okay I torture tested it on my MacBook Pro to over 72,000 tags. It took longer than I thought it would to add all those tags but it worked. WonderWare can't handle that many tags. (Not that I'm using WonderWare as a benchmark.) There is a linear search on the array to look for gaps in the database allocations big enough to fit the new tag. As the taglist fills up this search will slow down each tag. I don't think this is that big of a deal since adding tags is generally a start up and initialization issue and even at over 72,000 tags they were still being added at a rate of over 1,000 tags per second. I imagine that's fast enough.
Now I need to write some code to torture test the database, and see what kind of performance I can expect from the message queue, before I get too far down that road.