Comment 7 for bug 1278780

some thoughts upon analysis of /usr/share/apport/apport:

- apport does have support for blacklisting crash reporting for specific programs. For programs that are critical for the UI on the phone and which cause a hard lockup of the UI while the crash report is running, we could use this blacklist as a workaround.
- apport currently calls os.nice(10) to avoid interfering with the running system while processing the crash file. This is counterproductive when the process being retraced is critical to the system.
- apport's crash dump handling is already carefully written to avoid bottlenecks in either memory or disk writes (the crash dump is read from the kernel 1MB at a time, compressed, and written to the crash file); this should already be close to optimal (1MB may not be the optimal write block size, but it will compress to variable size anyway and we're not flushing the disk between writes so the kernel should do a better job of optimizing for us). Thus, aside from possibly dropping the call to os.nice(), I confirm that there's not much of anywhere for us to go in improving the performance of the crash handler. The only other thing that might improve performance is for the crashing process to simply have less mapped into memory at crash time - I guess that a crash dump of the unity system compositor would be quite large due to having graphics buffers mapped into memory?