Closed Bug 386897 Opened 17 years ago Closed 17 years ago

compile cairo/pixman with full speed optimization

Categories

(Core :: Graphics, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: vlad, Assigned: vlad)

Details

Attachments

(1 file)

I saw some significant codegen differences when cairo was compiled with -O2 vs. -O1 (optimize for speed instead of our default optimize for space). In particular, the _cairo_lround function which is used in some critical paths (win32 glyph drawing for one) is very expensive with -O1 but is inconsequential with -O2 (like 2500ms -> 30ms for a simple benchmark of the function). This patch enables speed optimizations for cairo and pixman. I don't know what the codesize hit would be, mind you, but I'm pretty sure that we should take it.
Attachment #270959 - Flags: superreview?(pavlov)
Attachment #270959 - Flags: review?(roc)
Do we trust GCC with -O3?
Gentoo's compilation optimization guide says "In 3.x, -O3 has been shown to lead to marginally faster execution times over -O2, but this is no longer the case with gcc 4.x." Feel free to draw you own conclusions, but mine is that if -O2 gives the 2500ms -> 30ms jump, then stick with it, -O3 probably isn't needed. (also, perhaps -Os should be benchmarked... it includes many of the optimizations in -O2 over -O1, and possibly the one that matters here is one of those)
Comment on attachment 270959 [details] [diff] [review] optimize cairo/pixman for speed, not space would it be better to optimize all of gfx this way?
2500ms -> 30ms by changing optimization options? Wow. I wonder if the gcc team would consider that a bug.
Summary: comile cairo/pixman with full speed optimization → compile cairo/pixman with full speed optimization
-O2 should be fine for gcc -- I was more speaking in terms of -O2 for msvc. The optimization block is what we use in a few other places where we want to compile with optimizations: sqlite and some other bits, though -O3 for gcc is probably a leftover from gcc 3.x. The 2500ms -> 30ms was under win32 msvc; it might or might not be a bug. That is, there was a significant performance gain from no optimizations to optimize-size, and another from optimize-size to optimize-speed; the function probably is a little bigger.
Attachment #270959 - Flags: superreview?(pavlov) → superreview+
Checked in with -O2 for both gcc and msvc.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Assignee: nobody → vladimir
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: