So I guess syncthing is using the memory (rather than SyncTrayzor). I suggest you create a separate thread about this in order to stay on topic.
Just want to mark my first issue with this. It does consume quite some memory, on mine I’ve seen it as high as 203MB just for SyncTrayzor’s process.
Also, opening it from the Notification Area and to open up the GUI takes up to 15 seconds, freezing the process. The same applies when I right click the icon and select exit.
i5 CPU with 6GB RAM (it’s a laptop)
@AudriusButkevicius In my process explorer, SyncTrayzor shows 300-400MB while syncthing shows ~30MB. same 10-15seconds freeze on opening in systray, as mentioned by @Rewt0r .
How can I or can someone move this post (and the following ones) to a new topic ?
Leave it here for the minute. I’m on GMT so it’s the end of the day here, but I’ll respond properly tomorrow.
Okay, so the memory thing might be off-topic depending on who is using the memory…
From my own experience: Windows code, even managed code in C# , can have horrible memory leaks You’d be astonished. Few are aware that certain types of managed C# code can leak memory like a sieve.
I only know this because of a robotics project I wrote years ago … The control system was on Windows in C# with a GUI… After running for 30mins to 60mins , the system would crash. I finally noticed my process (all managed code) was steadily growing in footprint as you used the app.
There’s a few ways this can happen… If memory serves me… (1) The Microsoft OCR library leaked memory. (2) The worst offendor was Image or Bitmap (and their classes and superclasses), (3) A few other libraries that are standard in C#
You can easily find out by running your app and checking it periodically with a memory profiler. http://memprofiler.com/screenshots.aspx
I don’t think this would apply to Go , as I seriously doubt Go leaks memory under normal circumstances
Wow your GUI looks slick … That’s Windows 8 , right? What are you developing it in?
I like your post “There is so much more information available through it and I like to see the status of my “mesh”” … I agree with this … However, I don’t know if this will have ‘mass appeal’. But it certainly appeals to me, heh.
“t should make the flows much easier, like adding a folder to multiple instances does no longer need approval on every instance if you have access through the REST-API.”
That’s actualy a clever idea. Would definitely make creating larger meshed networks easier (rather than log into each one via ssh and port forwarding for 8080).
Whoever put the Angular web services into Syncthing made a really really smart decision.
The memory usage I’d expect from SyncTrayzor is < 100MB, normally around 60 to 80 (as shown in Task Manager - i.e. numbers refer to Private Working Set). A lot of this is down to the embedded browser component.
Are you running the 32-bit or 64-bit build? Did the memory increase slowly over time, or did it jump up? Have you been closing to tray / restoring from tray a lot? When you say there’s a freeze when opening from the tray, is that an actual freeze (i.e. window is unresponsive, can’t open any menus - move the window), or just the browser bit loading?
Thanks!
Note that easy, you’ll find 
Quite often managed memory leaks will be due to either unsubscribed event handlers or static caches (e.g. of RuntimeMethodInfo, String) down in the CLR. The former are reasonably easy to figure out, but the latter can be a complete nightmare, since there’s no indication of what’s ultimately populating the cache.
I’m running the 64-bit build. And memory gradually increases (I’ve just closed it all, as it was around 490MB and hogging other processes). I’ll try bare Syncthing again, to keep my folders synced at least. Concerning the freeze, I thinl it’s rather the browser loading. Other open windows/processes slow down a bit but become responsive again after 10-15 seconds Thanks anyway for this nice work.
This is memory as measured in Task Manager - i.e. Private Working Set? Is it in your tray, or visible, while memory is increasing?
The memory usage should never get that high, and I’ve never seen it get anywhere near that! So something really odd is going on, and I’d like to pin down what it is.
Could you also post the contents of C:\Users\<You>\AppData\Roaming\SyncTrayzor\SyncTrayzor.log? (beware you may need to censor things like Device IDs). That might give us a clue too.
EDIT: Are you definitely running the latest version (v1.0.8)? You can see the version in Help → About. Version 1.0.1 had quite a bad memory leak…
I’ve also checked the current version. It’s always around 100-200MB, but I see that almost always 2 chromium instances are running, even when Syncthing is not active. Not sure what the second one does. Maybe it would be possible to get a detailed process hierarchy via Process Explorer to see where the memory went?
Yeah windows 7/8, C#, VS2013 with some GUI framework, Made some more progress, here is a preview, but it’s far from ready. I’ll make a dedicated thread as soon as it is somewhat useable, if ever. This is not the right place for it.
2 Likes
This looks darn awesome.
Which memory? Private working set? Private bytes? Working set? It’s important to distinguish which number you’re reading. Here’s a screenshot of Process Explorer with more figures turned on: in order, they’re, Private Bytes, Working Set, Private Working Set (WS Private) and Shareable Working Set (WS Shareable): http://imgur.com/oASZS5M. SyncTrayzor’s private memory usage is 70MB - the rest is shared libraries, most likely .NET: this memory is shared across multiple applications. Likewise the two CefSharp processes are sharing a good portion of their memory
You should see two CefSharp processes while SyncTrayzor is displayed/minimized, and one when it’s in the tray. I used to close as much as I could when SyncTrayzor was minimized, but that lead to Syncthing UI dialogs being closed, which was annoying. There’s no way to shut down CefSharp completely unfortunately: this is documented.
Sorry for replying a bit late (things to do IRL). I was running the 1.0.7 and updated to 1.0.8 (always portable) after your post. It has been on since then and I’m around 90-95MB (as displayed in Windows Task Manager). I’ll let it run until tomorrow but I think it’s better now.
I just counted how long it took to open, double clicking from the tray took 15 seconds for the window to appear then a further 25 seconds for the Chrome part to load. Whilst waiting for the Chrome part to load clicking any menu items took about 3 seconds each to display, the window could be moved around.
Will report back with memory usage as seems better atm. BTW I use x64 portable.
Thanks for the update. I’ve been doing a lot of profiling and testing this weekend. I’ve found a few places I can improve, and I’m now seeing typical memory usage around 60-70MB (as shown in Task Manager).
Interestingly, if I remove the the embedded browser component, memory usage drops to about 40MB, so that’s taking about 20-30MB of in-process memory, plus whatever’s used by CefSharp.BrowserSubprocess.exe.
I’ve added memory usage logging, which will be in the next release. If we can’t get to the bottom of this before then, maybe that will give us some more clues.
That’s definitely not right - I’ve never seen it take so long myself, so there’s something happening in your setup which isn’t present in mind, I presume. Does it respond quickly when it’s first been started?
Some more profiling later, and my managed memory usage is at about 6-7MB. Everything else is the embedded browser component, and .NET.
Again, if you’re seeing memory usage increase over time, please post the log file as I described earlier. That may give us some clues into that out-of-the-ordinary things are going on that may be causing this.
It’s also worth noting that I delay loading the embedded browser until the first the time that SyncTrayzor is maximized from the tray icon. So if you let SyncTrayzor autostart / start it with -minimized, you should see significantly lower memory usage (up until the point that you restore it from the tray icon).
Hello @canton7 ,
Sorry to reply so late…
Finally, the memory hog as displayed in the process explorer has moved from SyncTrayzor to the Syncthing process itself. It sometimes takes up to 95% of the CPU and almost all of the memory. But that is a Syncthing issue, right ?
By the way, thanks for the new version !
Other points (if I can ask for it here) :
-
Might seen “nooby”, I can’t find how to change the display language
-
Request : could you please resize (on create tabs on) the Settings box (File > Settings) ? It’s vertically so “tall” that it’s hard to reach the bottom options and the “Save” and “Cancel” buttons (I guess).
Thanks.
Interesting that it would “move”. Yeah, that’s a Syncthing issue. If you see SyncTrayzor taking up a lot of memory / being slow to respond again, please let me know! v1.0.9 has some logging around memory usage, and I’d love to see the logs.
SyncTrayzor will use your system language, if we’ve got a translation for it. Currently, we have de and nl-NL. If you want to explicitly specify a language to use, start it with the -culture flag, e.g. SyncTrayzor.exe -culture=de or SyncTrayzor.exe -culture=nl-NL. Beware that this is intended for debugging and you’ll get a crash if you specify an invalid culture!
If we don’t yet have your language, you can help 
See Localization · canton7/SyncTrayzor Wiki · GitHub
Issue opened:
Excuse my ignorance, but is this (even likely) to be incorporated into the official syncthing file, so that there is a windows installer, or is it always going to be maintained as two separate developments?