HywelPhillips
January 18th, 2021, 17:49
Hi,
FGU's performance is pretty good these days, but there is one place where it really slows down for me still - searches in the asset window.
I have a large number of assets because I have a lot of maps, tokens and map-making icons; I make a lot of my maps inside FGU now. All my data are in the SmiteWorks/images folder and subfolders thereof. It comes to 18 GB and 32490 items - a lot, but not a stupidly insane amount IMO. I've got most of the FGU art packs and the Devin Night token packs too.
I have verified that the same thing happens in a blank campaign (still with the same top-level images folder contents of course).
It works OK when used without a search term, and works OK with a long search term that doesn't return too many entries.
But if you accidentally choose too short a search term which gives a lot of results, I get the spinning wheel of doom and FG can lock up for minutes at a time. It's all too easy during a game to have to have an enforced tea break because I foolishly searched for "P" to the find the "P" letter token without thinking!
Happens in 5E and SWADE, so seems to be independent of ruleset.
For example:
searching images for "park" - 2 seconds
searching images for "par" - 30+ seconds
worse yet, it doesn't seem to cache results, so hitting the next page arrow incurs the same wait to display page two. Just resizing the window incurs the same wait, too.
I'm on MacOS Catalina 10.15.7 on a 10 core iMac Pro 128 GB Radeon Pro Vega 64 16GB system and everything is on SSD. Mac OS can search these same directories very fast (which I know is using caching via Spotlight, but it shows that the results returned aren't THAT overwhelming).
When it is waiting, FGU pegs CPU usage at 100%, so this is presumably single-threaded; the machine is sitting idle with 9 cores and the GPU twiddling thumbs.
At the very least it would be nice to cache the search output so once you've done the search the window can be resized and next arrows can be used without slowdown, but a different search implementation might be even better I suspect :)
Cheers, Hywel Phillips
FGU's performance is pretty good these days, but there is one place where it really slows down for me still - searches in the asset window.
I have a large number of assets because I have a lot of maps, tokens and map-making icons; I make a lot of my maps inside FGU now. All my data are in the SmiteWorks/images folder and subfolders thereof. It comes to 18 GB and 32490 items - a lot, but not a stupidly insane amount IMO. I've got most of the FGU art packs and the Devin Night token packs too.
I have verified that the same thing happens in a blank campaign (still with the same top-level images folder contents of course).
It works OK when used without a search term, and works OK with a long search term that doesn't return too many entries.
But if you accidentally choose too short a search term which gives a lot of results, I get the spinning wheel of doom and FG can lock up for minutes at a time. It's all too easy during a game to have to have an enforced tea break because I foolishly searched for "P" to the find the "P" letter token without thinking!
Happens in 5E and SWADE, so seems to be independent of ruleset.
For example:
searching images for "park" - 2 seconds
searching images for "par" - 30+ seconds
worse yet, it doesn't seem to cache results, so hitting the next page arrow incurs the same wait to display page two. Just resizing the window incurs the same wait, too.
I'm on MacOS Catalina 10.15.7 on a 10 core iMac Pro 128 GB Radeon Pro Vega 64 16GB system and everything is on SSD. Mac OS can search these same directories very fast (which I know is using caching via Spotlight, but it shows that the results returned aren't THAT overwhelming).
When it is waiting, FGU pegs CPU usage at 100%, so this is presumably single-threaded; the machine is sitting idle with 9 cores and the GPU twiddling thumbs.
At the very least it would be nice to cache the search output so once you've done the search the window can be resized and next arrows can be used without slowdown, but a different search implementation might be even better I suspect :)
Cheers, Hywel Phillips