Ported overhauled performance.md doc file changes #616
Conversation
RobinBateman808
requested review from
0xTim,
alexandersandberg,
daveverwer,
dempseyatgithub,
parispittman,
kaishin,
shahmishal,
cthielen and
federicobucchi
as code owners
|
@0xTim - ported changes to bump against performance.md file for comparison and mitigate link/reference issues. |
|
Hi @0xTim - just a friendly to remind you to take a look when you have a chance. Thank you! :-) |
|
Hi @0xTim - I'd love it if you could also provide your input on this doc. I added more instructions and explanations for those (like me/recent grads) who aren't as familiar with Swift/Swift on Server. |
|
|
||
| Outlined below are some basic tools and methods to debug performance issues in Swift: | ||
|
|
||
| 1. **Measure performance**: Use [Xcode’s Instruments](https://help.apple.com/instruments/mac/current/) and [Linux perf](https://www.swift.org/documentation/server/guides/linux-perf.html) provide profiling tools to track the performance of your application and help identify areas that consume excessive CPU, memory, or energy. For example, time profiling and flame graphs show the consumption of CPU, and memory graphs the consumption of memory. It’s important to note that each platform manages the measuring of your application’s performance differently. |
There was a problem hiding this comment.
| 1. **Measure performance**: Use [Xcode’s Instruments](https://help.apple.com/instruments/mac/current/) and [Linux perf](https://www.swift.org/documentation/server/guides/linux-perf.html) provide profiling tools to track the performance of your application and help identify areas that consume excessive CPU, memory, or energy. For example, time profiling and flame graphs show the consumption of CPU, and memory graphs the consumption of memory. It’s important to note that each platform manages the measuring of your application’s performance differently. | |
| 1. **Measure performance**: [Xcode’s Instruments](https://help.apple.com/instruments/mac/current/) and [Linux perf](https://www.swift.org/documentation/server/guides/linux-perf.html) provide profiling tools to track the performance of your application and help identify areas that consume excessive CPU, memory, or energy. For example, time profiling and flame graphs show the consumption of CPU, and memory graphs the consumption of memory. It’s important to note that each platform manages the measuring of your application’s performance differently. |
There was a problem hiding this comment.
@0xTim - I don't believe this makes sense ... "Use Xcode and Linux perf provide..." Maybe "Use Xcode and Linux perf to provide..." Reverted to avoid wordiness.
|
|
||
| 2. [Xcode’s Time Profiler](https://help.apple.com/instruments/mac/current/#/dev44b2b437): The tool profiles Swift applications during development, including server applications. It helps identify performance bottlenecks and provides a detailed timeline view of CPU usage to pinpoint and optimize problems. | ||
|
|
||
| > Important: For server-specific performance analysis, you may need to explore other profiling tools and techniques that are better suited for server-side environments. |
There was a problem hiding this comment.
I feel like this sentence needs rewording - this is the page to discuss tools and techniques so if we need to explore other tools what are they? I'm assuming this is just a reference to the time profiler in which case we either need to remove this or reword it
There was a problem hiding this comment.
Yes, this references the Instruments Help > Time Profiler > Track CPU core and thread use page. However, I'm open to removing Time Profiler as a tool since it seems like other tools work better and are easier to use. @FranzBusch - wdyt about listing (or not listing) Xcode Time Profiler as a tool?
|
|
||
| - Compatibility — Xcode’s Time Profiler tool is intended to work with applications running on macOS and iOS platforms. For server-side Swift applications, especially those running on Linux-based servers, using the Time Profiler directly may not be feasible. | ||
| - Remote Profiling — If you deployed your Swift server application on a remote server, you typically cannot directly use Xcode’s Time Profiler to profile its performance. | ||
| - Alternative Profiling Tools — To profile the performance of a Swift server application running on a remote server, you may need to use alternative profiling tools specifically designed for server-side performance analysis, like Instruments or specialized server-side profiling tools more suitable for this scenario. |
There was a problem hiding this comment.
Again, I think we should reword this. If Time Profiler isn't the right tool, what is?
There was a problem hiding this comment.
I agree it may be better to remove Time Profiler, even though it can work, it seems cumbersome. I looked up the recommended tools again to understand the performance characteristics of Swift server applications and optimize their performance which also included:
- LLDB debugger for Swift
- Third-parter profilers such as Speedscope (maybe ???)
- Swift Performance Testing
@FranzBusch - should we replace Time Profiler with any of these for server-side Swift?
|
|
||
| [Flamegraphs](http://www.brendangregg.com/flamegraphs.html) are a nice way to visualise what stack frames were running for what percentage of the time. That often helps pinpointing the areas of your program that need improvement. Flamegraphs can be created on most platforms, in this document we will focus on Linux. | ||
| > Note If you use `Set<Int>` to store the `FavouriteNumber`, the by-product should indicate if a number is a `FavouriteNumber` in constant time *(O(1)*). |
There was a problem hiding this comment.
This is confusing without any reference to existing code
There was a problem hiding this comment.
Added the original language back and lightly edited it. I also moved the code example above this "Note" for better visibility.
|
|
||
| ### Flamegraphs on Linux | ||
| #### Example program of an inefficient flame graph |
There was a problem hiding this comment.
This section should be at the top so it's clear what each tool example refers to
There was a problem hiding this comment.
Moved the example program back to the top of the section for better visibility and code reference.
|
|
||
| `> LD_PRELOAD=/usr/bin/libmimalloc.so myprogram` |
There was a problem hiding this comment.
I think we should keep an example of linking to jemalloc for example
There was a problem hiding this comment.
@0xTim - Although there is a direct link for the jemalloc example, I added a lightly edited version of the " LD_PRELOAD" code back into the malloc libraries section as suggested.
|
|
||
| # Step 3: Aggregate the recorded stacks and demangle the symbols | ||
| ~/FlameGraph/stackcollapse-perf.pl out.perf | swift demangle > out.folded | ||
| In Swift, memory allocation and deallocation are primarily managed by the [automatic reference counting (ARC)](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/automaticreferencecounting/) mechanism. However, there might be cases where you need to interface with C or other languages that utilize malloc libraries or if you require fine-grained control over memory management. |
There was a problem hiding this comment.
This last sentence needs to be tweaked. It's very easy to see memory issues if loading large objects into memory with pure Swift
There was a problem hiding this comment.
@0xTim - I'm not exactly sure what you mean. Can you please expand or change the language for accuracy and clarity.
Co-authored-by: Tim Condon <[email protected]>
Co-authored-by: Tim Condon <[email protected]>
Motivation:
I edited Debug Performance Issues and Analysis documentation to increase helpfulness.
Modifications:
I overhauled page content by adding definitions and clarity to existing content, editing for grammar and complete sentences, reducing wordiness, providing additional instructions for less-skilled users, and formatting for scannability.
Result:
Improve usefulness and increase user adoption.