{"id":31,"date":"2011-10-17T15:10:50","date_gmt":"2011-10-17T15:10:50","guid":{"rendered":"http:\/\/blog.mozilla.org\/nfroyd\/?p=31"},"modified":"2011-10-17T15:14:58","modified_gmt":"2011-10-17T15:14:58","slug":"reordering-plugins-and-edge-profiles","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nfroyd\/2011\/10\/17\/reordering-plugins-and-edge-profiles\/","title":{"rendered":"reordering plugins and edge profiles"},"content":{"rendered":"

Mike Hommey and I have been working with a linker plugin that uses the callgraph to reorder functions<\/a> on Linux and Android. One feature of the linker plugin is that it dumps a simplified representation of the callgraph to a text file. The simplified representation is really simple, just edge counts for all the edges in the callgraph. It’s not perfect, since the ordering of caller and callee in the dump file is not always consistent. Also, you get a few spurious functions in there, like __builtin_expect<\/tt> and SSE builtins calling things.\u00a0 (__builtin_expect<\/tt> just provides a hint to the compiler about how to order basic blocks for more cache-friendly control flow; SSE builtins should compile down to single\/few instructions and never actually call something at runtime.)<\/p>\n

Nevertheless, looking at the file for libxul.so<\/a> can be illuminating. Actually, it’s probably more illuminating to narrow things down to the edges with 100k+ call counts and demangled function names<\/a>. Doing that, we can see that:<\/p>\n