[haiku] Re: gcc4 hibryd

  • From: Ryan Leavengood <leavengood@xxxxxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Sat, 7 Mar 2009 18:45:16 -0500

On Sat, Mar 7, 2009 at 8:23 AM, Christian Packmann
<Christian.Packmann@xxxxxx> wrote:
> This will not be much of a problem on high-end machines, where web browsers
> cannot tax the CPU anyway, but on lower-spec machines this should be very
> noticeable, especially when rendering complex pages. This is a serious
> problem, as web browsers are one of the main applications in todays world.
> IMHO it wouldn't do to release Haiku R1, have people test it only to find
> that their web browsers work half as fast on Haiku than on Windows or Linux.
> This will certainly make an impression... just not a good one.

Since this is somewhat my current area of expertise/interest (web
browsers on Haiku), I'd be interested in any advice you might have to
solve or mitigate these issues. Since a lot of the browser computation
intensive code (box model, CSS calculations) are in the browser's code
and not the OS, could using higher optimization levels in GCC
(assuming the browser still works right) solve the speed issues you
brought up?

Since all the modern browser code we would want to use (WebKit, FF3)
relies on newer compilers anyhow, we really aren't stuck with GCC2,
but we would still need to make sure the proper GCC4 optimizations are
turned on.

I am not a compiler expert, but I assume optimizations that might not
work on Haiku as a whole could still potentially be used in
application code. Plus maybe selective parts of Haiku could be
compiled with certain optimizations and then thoroughly tested to be
sure they still work right. In this way maybe Haiku could get all the
optimizations eventually by a divide and conquer approach.

I am very interested in having Haiku perform as well or better than
BeOS, and intend to test my browser work on slower machines, so I will
soon find out just how true your worries are (and I think they are

Any advice is appreciated.


Other related posts: