Im not sure if this has been improved in 7.3, but its a big problem for me in 7.2.11. I have a large project with around 65k tags, and they are spread around in around 1600 tag folders.
Trying to make changes in the designer is very slow and cumbersome for me. Just getting a folder to drop down so I can see the tags contained in it can take minutes. If I rename a folder, it can take 5 or so minutes before I can do anything in the tag browser.
Is this something I will have to live with or is their anything I can do to speed this up? This is a internal sqltag provider.
We have done a lot of memory improvements in 7.3. You should give our tech support team a call at (800) 266-7798 and press 2. That way we can look at it to see what is going on.
You can also try upgrading to 7.3 to see if it helps.
I suspect your problem won’t be helped too much by 7.3… in fact, it may be made worse! See, Travis is right, memory was improved- partially be reducing the amount of config data held in memory. However, the tag browsing currently requires the full definition of the tag, so in 7.3, we now have to load them from the internal DB during browse. So, if you didn’t plan on updating to 7.3, I would hold out for a bit longer.
It so happens that I’ve been looking at this system quite a bit recently as we work on UDTs in SQLTags for 7.4. I think there may be some base inefficiencies that can be improved, and I think in cases like yours, a big difference that could be made by not requiring the full tag to be returned from the browse. I’m going to look into profiling the tag browse system on monday, and hopefully can come up with some more info. I hope that for 7.4 we can improve it quite a bit.
I have a question, just in case I end up building another system of this size. as of right now, is there anyway I can setup the system to better handle a large amount of tags? like using a db driving provider, or what about having folders inside of folders. like maybe splitting up the folders according to region, like 400 device folders in east, 400 in west, etc. would anything like that make a difference?
Its not a huge issue, for the most part I can use csv files or scripting to do what I need… but it is just really slow when trying to do some basic troubleshooting.
Yes, breaking the tags up into sub folders would help. The overall time to browse everything would more or less be the same, but at least it would be broken up quite a bit, as only the folder that is expanded would be browsed.
I’m nowhere near 65k tags, (only) 7k spread across 40 or so folders.
There is one thing that occurs when editing tags that would be great: when creating a new tag, or changing the name of an existing tag, the whole tag tree view refreshes and you are now looking at the start of the list… this becomes a pain when you start getting up around the couple of hundred tags in one folder mark.
Otherwise I have just found the tag search feature, which is fantastic. The only way this could be improved is if there was a search bar at the top of the tags browser that acted a bit like google instant in terms of filtering tags as you typed letters in.
I have something similar working on one of my programs… essentially binding a datagridview results to be filtered using something like "SELECT * WHERE [tag] LIKE " that is fired from the key pressed event.
I absolutely agree, I hate the way the tree refreshes right now. We’re going to do a bunch of work soon after the 7.4 release to address many issues like this, and this is something that has been bugging me for a while.
great. yeah, when the tree refreshes after renaming a tag in my system, it turns into a 5 minute ordeal. still beats the heck out of not having a “live” designer.
still beats the heck out of not having a “live” designer.