[Feature] How to improve the loading speed? about systemtraymenu HOT 6 OPEN

@Dean-Corso

Thank you for the feedback!

yes, the live update we made with
#330
This should only affect the loading speed very slightly. We collect the events delete create move file and run it on the cached content so we don't always have to read everything. Theoretically we could load everything and still keep the live update.

we read the main folder and all added to the main folder when the app starts.
Therefore, if it is a folder that has already been added to the main menu, then there would be no performance advantage here. These items are already read at the start of the app.
We can't preload all subfolders, since that would basically be the entire hard drive with drive C if you have C as the main folder.
Respectively, many subfolders may not always be opened, but only certain ones.
We tried it out at the very beginning/early versions of STM and yes, there are very long loading times at the beginning. But when you start the PC, you really want to access the STM as quickly as possible.
I think we not want to change that we read more than main menu and the addional directories at app start.
(also consider that we restart the app when the settings are changed, so that user has to wait also there too)

somehow we don't see a real problem. If you feel like it, you can make us a video of the behavior.

I'm going to show you a video here.
I have e.g. my apps as a directory to the main folder.
When you change the settings, the app is restarted, and the app folder is loaded when it starts. You can see that briefly in the video. If I then go to the app folder, the icons are already in the cache. Then I open another less frequently used folder 'Smart Home'. You can see the icons are loaded in a few milliseconds.

This may also be due to the fact that I use an ssd drive (instead hdd drive), with an hdd it may take longer to load the icon there, but we can't really improve that.

Or it should be like this if it was added as a directory to the main folder, it queries the icons when the app is started and then it should not have any loading time when open the related subfolder since the icons are already in the cache.

Related to other topic 'Round Corners':
we could now only change the radius. The method we use for this is very old and doesn't look perfect. We do it better with the v2 under WPF. Find it here https://github.com/Hofknecht/SystemTrayMenu/tree/v2.x, but there is still a lot to do )

Related to other topic 'Gradient background' / 'images background':
we have a performance issue when introducing this, so we removed it
#268
that will come back later when v2 under WPF, which has hardware acceleration, so it uses also GPU

from systemtraymenu.

Hello @Dean-Corso
Thank you for the feedback!

We think we understand what you mean and try to explain the behavior and how to improve it.

You can find the code at menu.cs
public static MenuData GetData(BackgroundWorker worker, string path, int level)

To display a menu we need the contents of the folder. We then find out whether it is a folder, network path, read the file info, from this the path, file extension, from this then whether it is a link, if it is a link, then we resolve the path if necessary and we then also read the file name .
After reading the content, we display the menu.
If the associated icon can be read immediately (because it loads very quickly or because it's in the cache), then we show that right away, otherwise it's read in the background and a loading icon is displayed while it's running.

We understand that loading this icon in the background takes about 10 seconds. There can be reasons for this, in principle we use native methods for this.

see also IconReader.cs
private static Icon GetIcon(string path, string resolvedPath, bool linkOverlay, IconSize size, bool isFolder)

Unfortunately, we think that there is nothing that can be speeded up directly here.
Maybe windows explorer does this with thumbnails using its own windows cache, so windows explorer can somehow load that faster. Loading the icons kept us busy for a long time, unfortunately there doesn't seem to be an easy way to get them. If I'm wrong here please correct me.

So we decided back then to load the icon in the background so that the UI doesn't freeze and the menus open quickly. Furthermore, we have a cache for all items from the main menu and one for all items from all sub-menus.
Here you can of course increase the cached items from 200 to e.g. 400, then it would reload said folder the icons less often. But that uses more GDI objects.
The problem was with the GDI objects if you e.g. once you open the system32 folder of windows you have a lot of items in the cache, we wanted to prevent that. With more GDI objects the application becoms slightly slower and at 10.000 it crashes, you can view GDI objects with Task Manager.

The items in the main menu have their own cache. Another solution I would think of here is that you add the one folder that is the problem to the 'Directories' options. These additional files that are added to the main menu are treated like items from the main menu, so there is virtually no cache limit. So the issue would be at least limited to the application start.

Maybe that helps already? we can discuss the topic further here. It's best to add it to directories and give feedback if that helps.
You can set the flag 'Show only as search result' then they are not directly visible and disturbing in main menu.

Looking forward for your feedback and discussions here

i will flag as FAQ

from systemtraymenu.

Hello Markus,

thank you for your answer so far and trying to explain the problem. So I do understand that it can +/- time to load entire content of all folders/path/icons and to display them if you do it on fly. I also have already added all folders into the directories tab because I also need to find those tool names I have added via search mask but this also didn't increase the speed.

So I do remember that in some of your older versions I had to re-start your app after adding a new file (.lnk) into the system try main folder because your tool didn't recognize the update. So what is if you just add some new function to read all datas on app start and store them into internal buffers and when the user does use your app to get the content displayed then you can just access your internel buffers / read datas / display them super fast. This method would be some kind of static single read & store and no more update on fly. The dis-advanatge would be the missing update status.

Example: At the moment your app works somehow to read datas on user access / on fly to show all infos in realtime right. When I as user add some new files into STM folder/s then it will also recognize them and show them too. All fine so far.

Now you could add another option for the users just to read all files from STM folder/s on app start only (just once) and then you just read / store all infos you need in buffers and do access/read from them when the user does access STM etc to prevent another refresh reading / checking for new items what does save time and you can display all menus right away without any waiting times. When the users now add some new items into the STM folder then STM till NOT update this in this case. So for this little problem you could just add another function called "UPDATE" just adding a another gray icon and place it next to the pin icon / setting icon / re-start icon the user can click on it and then your app does re-read all datas new. So what do you think about that as alternative method for users who would prefer this way?

Info: Round Corners. So this isn't looking really nice. They are too angular instead of round. Maybe you could work on a better owner draw to make the look some better or something. Also some gardient fill color mix would be welcome too instead of using pure colors what dosen't look very nice. What about a image / wallpaper as background? Some little more stylish features would be not wrong or? Of course, these are just addon requests only (no must).

PS: Wie gesagt, deine App ist super und gehört zu meinen "MUST HAVE" tools! Dickes Lob schonmal dafür! 😃

from systemtraymenu.

@Dean-Corso
I forgot last time to answer to this:

Could you add also a item count info for all items like this....
items 23 | all items 183

That would be possible, but you can also see it by typing '*' in the search bar. we don't need this information often, maybe that's enough to check by typing the star. Otherwise it's best to open new issue for this.

and this

on that search bar at the top of each panel is the right mouse button / context menu not working to show anything so thats bad because I want to past some text / name into that edit control. Just wanna ask whether you can enable it or whether you could add just small button at the end to past text from clipboard into etc. Something like that would be nice to prevent using keyboard each time to enter something you know. Thank you.

I think we intentionally removed this context menu. I don't even know why. Yes, we should probably put that back in.
e.g. there is also a right click paste in windows start menu => i added new issue here #466

if I have forgotten more, please write again or create new issue for new topics.

Thank you for your praise of the tool, we're really pleased : )

from systemtraymenu.

Hello @Hofknecht,

so I understand your point you don't wanna change it back again to old refresh method when some new item/s was added etc but you could add this old way as custom setting / user choice (not default) to enable it you know.

Yes of course, so there is no real problem with your app which works 1A and I'am just wail on a higher level (there is no serious problem or anything like that). Normally I start STM via Windows autostart to have in my tray and when I need to load any app I do use it. The thing is that the first main tab gets always loaded without any waiting time and it opens just right away but then when I go on the first folder to open the new tab then it stops and I have to wait a longer while and this is a little annoying if this happens. But after this the access is very quick a longer while. Not sure how long I have to wait to reproduce this problem another time etc. Fact is, when I start my PC then Windows is ready to use (20 seconds I think / SSD) and I go then on STM and wanna see into any folder (like you did in your video) then I have this waiting problem. I think somehow it could be possible to read all item datas on first run of STM in hidden modus so that I as user don't need to access every folder manually with the mouse in STM to make them load / show. So if you just do this by the app itself then you have all datas in cache already which should then make the loading faster. So I think I would implement both loading versions for the users. First one is the live update method as it does now already = default mode and second could be old static load & store method without live update (just needs restart to read new items) but right away showing all items. So in my case I'am adding not offten new items what makes a live update superfluous for me and I would prefer a quicker load & show items method you know. Other people would prefer live update and then it would be maybe a good idea to have the choice of any of them you know.

Ah ok now I see it when I enter '*' into search bar. 😃 So this I didn't tried to enter before but also in this case you have to use the keyboard itself again. Just remember, many people do not like to use the keybord / key-shortcuts and prefer using just the mouse. Otherwise you could also think about people with some "Handicap" what could impair their normal actions and can not using keyboard so easy etc. I always asked myself why there is no MONO audio switch on the video player on youtube (just a example). You have many option on the YT player (subtitles, quality, playback speed, mini - theater - fullscreen) but no audio mono switch and the question is why not? They just don't think about people with hearing handicaps (left / right) and if an audio is just playing at one side or mixed then they have the problem to hear everything and then it makes also sense to set the audio to mono to get all on both sides (left & right). As I said, thats just a example (farfetched). So, compared this example to your app would it mean that a another info for all items (items 23 | all items 183) would make sense and save a detour to get that information.

Yes, adding a simple paste menu entry in searchbars of your app would be good.

Ok, if it makes too much trouble with performance doing some graphic / design changes then its better to skip that and keeping the performance in good working state.

PS: By the way, I will try to make a video tomorrow to show you the long waiting time on first use after starting the PC.

from systemtraymenu.

@Hofknecht,

Ok I made a short video where you can see the waiting process right after using your tool first time after PC start. Just have a look to see this issue....

from systemtraymenu.