| Summary: | [GTK] Compiler flags for optimization | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Alp Toker <alp> | ||||
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | berto, mjs, mrowe | ||||
| Priority: | P2 | Keywords: | Gtk, Performance | ||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Attachments: |
|
||||||
We build with -fomit-frame-pointer disabled on the Mac as it makes backtraces from production builds next-to-useless. Our measurements show it'd be approximately 5% speedup on the JS iBench though. Created attachment 17742 [details]
Optimization flags
The biggest problem with this patch is that -fstrict-aliasing in JavaScriptCore.pri ends up affecting the whole build and getting applied to WebCore, which is not correct. We only want it to apply to JSC.
-fno-exceptions -fno-rtti landed in r28651. Other flags still up for discussion. Old bug, I'm closing it as it's no longer relevant, the flags discussed here are either already present or implicitly defined by -O2. |
There are some compiler flags which may help increase performance and reduce footprint in the GTK+ port. Some appear straightforward, given that we make no use of exceptions or rtti in JSC, WebCore or WebKit (these mainly help reduce code size, but also improve performance): -fno-exceptions -fno-rtti Others flags reported to yield benefits by the Apple WebKit team: -O3 makes a big difference over -O2 -fomit-frame-pointer is a big win Reportedly significant for JSC: -fstrict-aliasing Some other flags I noticed, that may or may not be relevant: -fmessage-length=0 -fvisibility-inlines-hidden -fno-threadsafe-statics Some of these flags shouldn't be used in Debug builds I'm guessing. -fomit-frame-pointer has a bad reputation -- we might have a hard time convincing distributions like Debian to leave it on. Numbers might help. Is this an accurate summary? Any flags that I've missed, or any that are redundant? Is it worth using a different set of flags for JavaScriptCore and WebCore? It might be easier to just use the same flags for the lot with our current build system. (I've successfully made a build with all those flags enabled.)