Synergy memory usage

There is an old, now closed bug report for Synergy's memory usage here:

https://wincent.dev/a/support/bugs/show_bug.cgi?id=21

The bug was closed because Synergy has no known memory leaks. You can see if it's leaking any memory by running the "leaks" command line tool (probably need to have the Xcode Tools installed in order to have "leaks" on your system).

Here is the output of "leaks" run on Synergy immediately after launch:

Code:Process 668: 45804 nodes malloced for 3191 KB Process 668: 12 leaks for 1472 total leaked bytes. Leak: 0x01863800 size=1024 string 'DRHT' Leak: 0x00369420 size=80

       0x767f469f 0x00000020 0x00366f30 0x00000001     .F.v ...0o6.....
       0x00000000 0x00000000 0x00000000 0x00000000     ................
       0x00000000 0x00369470 0x00000000 0x00000000     ....p.6.........
       0x00364880 0x00000002 0x00000002 0x00000000     .H6.............
       0x00000000 0x00000000 0x00000000 0x00000000     ................

Leak: 0x00369470 size=80

       0x767f46cf 0x00000000 0xa2ddc61c 0x00000001     .F.v............
       0x00000000 0x00000000 0x00000000 0x00000000     ................
       0x00000000 0x00000000 0x00369420 0x00000000     ........ .6.....
       0x00364880 0x00000000 0x00000002 0x00000000     .H6.............
       0x00000000 0x00000000 0x00000000 0x00000000     ................

Leak: 0x00366f30 size=64 instance of 'NSCFString'

       0xa0806260 0x0001078c 0x6d6f6329 0x7070612e     `b......)com.app
       0x482e656c 0x6f6f5449 0x786f626c 0x6e69772e     le.HIToolbox.win
       0x67776f64 0x70756f72 0x6f642e73 0x656d7563     dowgroups.docume
       0x7f00746e 0x00000000 0x00000000 0x00000034     nt..........4...

Leak: 0x003a2c70 size=32 string '~' Leak: 0x003a2c50 size=32 string '1' Leak: 0x003a2bd0 size=32 string 'j' Leak: 0x003a2ae0 size=32 string '}' Leak: 0x003a29d0 size=32 string 'G' Leak: 0x003a29b0 size=32 string 'Q' Leak: 0x00370230 size=16 string Leak: 0x00393b40 size=16 string

This shows a couple of leaks not in Synergy due to bugs in the system. You can check this out for yourself by creating a new empty application project in Xcode. Build the empty project and run it and you'll see some leaks. These are unavoidable but they're no big deal either because as you can see it is only a handful of bytes and it doesn't actually grow: it's a fixed amount. There is also a known leak associated with the use of AppleScript, again an unavoidable Apple bug, but again not a big deal as we're talking about only a few bytes and Synergy's use of AppleScript is minimal (most of the work is done using raw Apple Events instead).

If I keep running "leaks" on Synergy then the leaked bytes count stays at 1472 bytes:

Code:Process 668: 45798 nodes malloced for 3191 KB Process 668: 12 leaks for 1472 total leaked bytes.

This after launching iTunes:

Code:Process 668: 50339 nodes malloced for 3709 KB Process 668: 13 leaks for 2496 total leaked bytes.

It appears we've leaked another 1000 bytes but in reality we haven't because running "leaks" again a few seconds later yields the following:

Code:Process 668: 51010 nodes malloced for 4351 KB Process 668: 12 leaks for 1472 total leaked bytes.

So you can see memory usage going up due to things like retrieving album covers from iTunes, but no memory is being leaked.

Finally, here's the report after several minutes of heavy thrashing: skipping tracks in iTunes, using Synergy's menu bar control buttons, using the hot keys, navigating the global menu.

Code:Process 668: 53041 nodes malloced for 6416 KB Process 668: 23 leaks for 2064 total leaked bytes.

A few hundred bytes leaked due to use of NSAppleScript, but as I said above that's unavoidable. A few minutes later and we get this:

Code:Process 668: 52905 nodes malloced for 6378 KB Process 668: 23 leaks for 1056 total leaked bytes.

The leak count has actually dropped lower than ever, to just 1056 bytes (and overall memory use has dropped too). These minor variations are caused by the fact that "leaks" is not a perfect tool and it can't reliably determine if memory really is leaked or not 100% of the time (see the leaks man page for full details). But I have run these tests many times over the years and even when Synergy is left running for weeks on end the leaked memory is only ever a few bytes.

The memory usage is going up due principally to album covers being cached in memory, but the system is very intelligent when it comes to managing virtual memory so the best thing that you can do is just let the system handle it. Memory that's not accessed frequently will just get written out to disk when another app needs memory. If that memory is needed again later by Synergy then the system will read it back from the disk, but the actual swapping traffic caused by Synergy is actually very low due to the intelligence of the system.

Leaks are programming errors and I always fix them when I find them, but as you can verify yourself there are no more leaks and there haven't been for many versions. I could try to make Synergy cache less but it wouldn't actually lead to better performance as I doubt that I could manage my memory better than the geniuses who wrote the Mach VM could...

There are two times when Synergy can obtain a new cover:

1. When iTunes starts playing a new track and has a cover for the track

2. A cover gets downloaded from Amazon.

The latter case usually happens during playback but could conceivably happen when iTunes is not running if you have a lot of tracks without artwork, have played them all recently, and Synergy added them to the "search queue".

If your system is pausing for 10-35 seconds then that is very worrying indeed and I wonder what's up. Synergy using 150 meg of that memory (10% of your memory) is not enough to explain such a delay. From your screenshot I see you have 1.5GB of RAM which is a decent amount. The system is generally very generous with the amount of memory it gives to each process, which is why the top ten apps in your list all have well over 300 meg each, even the small apps which don't do much. But like I said, usage of that kind of scale should most definitely not result in any user-noticeable slow-down. I think there must be some other cause.