First published on TECHNET on Jan 14, 2016
Skype for Business and Lync 2013 clients manage memory differently than previous client versions. This article describes the design change, how it impacts client performance, and how it affects the memory footprint. For purposes of this article, the term “Lync 2013” relates to Lync 2013 and Skype Business clients. At the time of this writing, the executable name for Lync 2010, 2013 and Skype for Business clients is lync.exe.
: Lync 2010, 2013/Skype for Business 2013
At a high level, the difference between Lync 2013 and Lync 2010 memory usage patterns stem from two main changes. Each change will be discussed in more detail below.
Lync 2013 does not proactively flush working set memory
Lync 2013 uses shared office components
Working Set Trimming
Lync 2013 relies more on the operating system to manage memory compared to Lync 2010. This allows the lync.exe process to effectively utilize physical memory when available and at the same time allowing the operating system (OS) to trim lync.exe’s
when other application demand more. By allowing the OS to manage physical memory, Lync 2013 can reduce the number of page faults thereby improving the overall system performance.
Lync 2010 performs explicit flushing of the working set memory when the main window of the application is minimized or closed to run in system tray even when physical memory is already available for use by other applications. This explicit flushing of the working set consumes operating system resources, and causes page faults when the Lync application demands more physical memory from the paging file. This impact can be observed by measuring the number of page faults when Lync client is minimized/running in system tray and executing core scenarios like receiving IM, receiving P2P audio call or joining a meeting. In real time communication scenarios, this impact can translate to delays in effective use of the application.
Page faults occur when there is not enough physical memory on the machine to meet memory demands. When this occurs, memory is copied from physical RAM to a swap file on the hard disk drive, and then make room to enable the requested memory allocation to complete. This is a very expensive operation because this swap requires a series of reads and writes on the hard disk drive, and this process must be completed before the operation that caused the fault can resume.
In Lync 2013, if the OS needs the memory for other programs, lync.exe’s working set will still get trimmed, but only when needed. This design change improves the overall performance of Lync 2013, and the host machine as well.
The graph below is a sampling of the page faults for 2010 and 2013 collected on the same machine, running the same Lync account while executing the same set of scenarios in the same sequence.
As you can see there is a significant decrease in the number of page faults for Lync 2013\Skype for Business:
The graphs below show Page Faults/sec and Working set memory while executing the above scenarios.
Shared Office Components
Lync 2013 is more strongly integrated with other office components and shares several office components and resources. This move effectively allows Lync 2013 client to provide a much richer user interface (UI) experience compared to Lync 2010. Reusing office components has also increased the working set of Lync 2013 compared to Lync 2010. This increase in working set can be attributed to advanced caching strategies, use of hardware vs software rendering when appropriate, animations and fluidity of the user experience (UX).
In addition to richer UX, sharing office components allows Lync 2013 to share working set with other office applications running on the same machine consuming the shared components. This can be observed by capturing a virtual memory snapshot of Lync process and another office application (Outlook -2013) running on the same machine and components like msod.dll loaded into memory (working set) is being shared by both the applications.
With Lync 2013 being part of office suite of applications, many users have Lync & other Office applications (Outlook, OneNote) running on the same box. This combination results in a much more effective usage of working memory set even though the working memory size is bigger when viewed individually from Lync 2013 as a standalone application. Lync 2010 running on the same box as other Office applications does not share Office components in memory, effective resulting in less effective usage of working memory set across applications.
Implications of These Changes
You might notice that the Lync 2013 client may use a significant amount of memory, depending on how long it has been running, and what activities have been performed with the client. When looking at a graph of Private Byes, Virtual Bytes, and Working Set in Performance Monitor, you might see a constant increase in these counters for lync.exe, especially during the working day. These counters will typically not decrease overnight if lync.exe is left running.
For some applications that trim their own working set, this could be a sign of a memory leak. However, because of the design changes mentioned above, chances are good that this is NOT a leak. The real question to ask is whether there any actual performance problems associated with this level of memory consumption, with this application, other applications, or the operating System? If real performance problems are seen, further investigation would be warranted.