![]() ![]() Some of the new tag sibling application rules may have 5-10 minute delays on edit as well. On an SSD with the PTR synced, about 10 to 20 minutes, depending on how many files you have. The update this week will take some time as a new cache is generated. I had a great couple of weeks moving tag siblings forward. In particular, tag processing speed, which took a real hit, is back up to good speed, and setting new tag sibling application rules now only needs to regenerate for changed siblings, so if you add (or remove) your own five 'my tags' siblings onto the PTR, the client now only has to do two seconds of work, not ten minutes. It depends on many factors, but many things are faster overall. I put a lot of time into this this week and was very successful - some sections take 10% less time, some 90%, and one critical query now takes 99% less time. Unfortunately, a couple of areas were working inefficiently, which IRL testing helped to diagnose. I am very happy that there do not seem to have been any obvious errors with the new sibling database cache. I had a great week fixing some bugs and optimising the new tag siblings cache. And you should find many types of file search, particularly those with multiple search predicates, and general tag processing, should be faster than before. If you found some systems (like the 'related tags' suggestions in manage tags dialog) sometimes took a few seconds to work in the past couple of weeks, they should now be fast again. A database technique I use for many purposes is now more reliable (fewer lag spikes), and has less CPU overhead. I wasn't as productive as I hoped, but I am happy with the mostly optimisation work.Īfter some more profiling in IRL situations, and with more helpful info from users, I have done another round of profiling for the new sibling cache, and more besides.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |