Speed
The NetSurf web site says: Efficiency lies at the heart of the NetSurf engine, allowing it to outwit the heavyweights of the web browser world. The NetSurf team continue to squeeze more speed out of their code. I've been doing one or two comparisons on a 300MHz Kinetic RiscPC running OS 6.16. Test 1 - following a link to near the bottom of a thumbnail index. Fresco 2.13 15s Oregano 1.1017s Netsurf r11515 28s Test 2 - following a link to the latest forum post from the top 10 latest posts page. Fresco 4s (when it worked properly) Oregano 6s Netsurf 17s Now obviously there's a big advantage in coding in assembler for a specific processor family rather than using C and making the code portable, but the main reason seems to be that NetSurf is trying to reformat the whole page over and over again, taking note of dimensions only after the images have been downloaded. The other browsers do a quick format observing dimensions where given, download the images and then reformat if necessary. Oregano seems to fill in the visible part of the window first which is a nice feature, but in the above tests I waited for the page to finish downloading. -- Richard Porterhttp://www.minijem.plus.com/ mailto:r...@minijem.plus.com I don't want a user experience - I just want stuff that works.
Re: Speed
On Fri, Feb 04, 2011 at 11:42:03AM +, Richard Porter wrote: The NetSurf web site says: Efficiency lies at the heart of the NetSurf engine, allowing it to outwit the heavyweights of the web browser world. The NetSurf team continue to squeeze more speed out of their code. I've been doing one or two comparisons on a 300MHz Kinetic RiscPC running OS 6.16. Test 1 - following a link to near the bottom of a thumbnail index. Fresco 2.13 15s Oregano 1.1017s Netsurf r11515 28s Test 2 - following a link to the latest forum post from the top 10 latest posts page. Fresco 4s (when it worked properly) Oregano 6s Netsurf 17s Now obviously there's a big advantage in coding in assembler for a specific processor family rather than using C and making the code portable, I wouldn't call it an advantage. And none of the browsers you list here are written in assembler; they're all written in C. but the main reason seems to be that NetSurf is trying to reformat the whole page over and over again, taking note of dimensions only after the images have been downloaded. Also, NetSurf implements *FAR MORE* of HTML and CSS than either Fresco or Oregano. The amount of work it is doing is an order of magnatude greater. The other browsers do a quick format observing dimensions where given, download the images and then reformat if necessary. Oregano seems to fill in the visible part of the window first which is a nice feature, but in the above tests I waited for the page to finish downloading. You know where the sources are, etc... B.
Re: Speed
On 04/02/2011 11:42, Richard Porter wrote: The NetSurf web site says: Efficiency lies at the heart of the NetSurf engine, allowing it to outwit the heavyweights of the web browser world. The NetSurf team continue to squeeze more speed out of their code. I've been doing one or two comparisons on a 300MHz Kinetic RiscPC running OS 6.16. Test 1 - following a link to near the bottom of a thumbnail index. [snip] Test 2 - following a link to the latest forum post from the top 10 latest posts page. [snip] How about URLs so people can see what those pages contain? Such as CCS elements which the older browsers will just ignore. Now obviously there's a big advantage in coding in assembler for a specific processor family rather than using C and making the code portable Coding in assembler is a big disadvantage for any sizeable amount of code. You wont find any modern web browser written in assembler, it would be insane. -- David J. Ruck email: dr...@druck.org.uk phone: +44(0)7974 108301
Re: Speed
On 4 Feb 2011 Rob Kendrick wrote: Now obviously there's a big advantage in coding in assembler for a specific processor family rather than using C and making the code portable, I wouldn't call it an advantage. And none of the browsers you list here are written in assembler; they're all written in C. OK, so that takes away one possible reason for the difference. but the main reason seems to be that NetSurf is trying to reformat the whole page over and over again, taking note of dimensions only after the images have been downloaded. Also, NetSurf implements *FAR MORE* of HTML and CSS than either Fresco or Oregano. The amount of work it is doing is an order of magnatude greater. The test pages were 'any browser' compatible so Netsurf didn't have to do far more than the other browsers. -- Richard Porterhttp://www.minijem.plus.com/ mailto:r...@minijem.plus.com I don't want a user experience - I just want stuff that works.
Re: Speed
On Fri, Feb 04, 2011 at 12:00:49PM +, Richard Porter wrote: Also, NetSurf implements *FAR MORE* of HTML and CSS than either Fresco or Oregano. The amount of work it is doing is an order of magnatude greater. The test pages were 'any browser' compatible so Netsurf didn't have to do far more than the other browsers. As I said, you know where the sources are if you think you know better. B.
Re: Speed
In article 66463fa051.r...@user.minijem.plus.com, Richard Porter r...@minijem.plus.com wrote: The NetSurf web site says: Efficiency lies at the heart of the NetSurf engine, allowing it to outwit the heavyweights of the web browser world. The NetSurf team continue to squeeze more speed out of their code. I've been doing one or two comparisons on a 300MHz Kinetic RiscPC running OS 6.16. [Snip] One thing occurs to me; you are using r11515 which is a development build of Netsurf which has with it a warning Notice: At any given time these builds may be unstable or have verbose logging enabled which could compromise performance of the browser, have you fallen foul of this? Maybe a comparison with the most recent release version might give a different result. -- _ Brian Jordan Virtual RPC-AdjustSA RISC OS 6.20 _
Re: Speed
On 4 Feb, Richard Porter wrote in message 26fe40a051.r...@user.minijem.plus.com: On 4 Feb 2011 Rob Kendrick wrote: Also, NetSurf implements *FAR MORE* of HTML and CSS than either Fresco or Oregano. The amount of work it is doing is an order of magnatude greater. The test pages were 'any browser' compatible so Netsurf didn't have to do far more than the other browsers. I'm not sure that logically follows. NetSurf still has to know how to do far more than the other browsers, for pages that /do/ contain more modern features, and selective amnesia might be even more inefficient overall. (I don't know for sure as I don't know that much about the layout engine in NetSurf, but your logic seems faulty to me). Also, define any browser compatible. These days, I'd take that to mean lots of CSS and not Fresco-friendly; YMMV. -- Steve Fryatt - Leeds, England Wakefield Acorn RISC OS Show Saturday 16 April 2011 http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
Re: Speed
On 4 Feb 2011 David J. Ruck wrote: On 04/02/2011 11:42, Richard Porter wrote: The NetSurf web site says: Efficiency lies at the heart of the NetSurf engine, allowing it to outwit the heavyweights of the web browser world. The NetSurf team continue to squeeze more speed out of their code. I've been doing one or two comparisons on a 300MHz Kinetic RiscPC running OS 6.16. Test 1 - following a link to near the bottom of a thumbnail index. [snip] Test 2 - following a link to the latest forum post from the top 10 latest posts page. [snip] How about URLs so people can see what those pages contain? Such as CCS elements which the older browsers will just ignore. Test 1 has no CSS or javascript. Test 2 has some inline style elements and javascript (http://www.minimarcos.org.uk/cgi-bin/forum/Blah.pl?,b= MM,v=display,m=1296606335,s=4,highlight=#num4). I don't think the javascript contributes to the formatting of the page - it's more concerned with confirming delete requests, which obviously doesn't work in NS. Now obviously there's a big advantage in coding in assembler for a specific processor family rather than using C and making the code portable Coding in assembler is a big disadvantage for any sizeable amount of code. You wont find any modern web browser written in assembler, it would be insane. According to Rob the older browsers were written in C anyway, so that's not a factor. I agree entirely with your second sentence for a whole raft of reasons, but execution speed isn't one of them. -- Richard Porterhttp://www.minijem.plus.com/ mailto:r...@minijem.plus.com I don't want a user experience - I just want stuff that works.
Re: Speed
On 4 Feb 2011 Rob Kendrick wrote: As I said, you know where the sources are if you think you know better. Point noted but I think the 'dancing around' is more of a design problem. -- Richard Porterhttp://www.minijem.plus.com/ mailto:r...@minijem.plus.com I don't want a user experience - I just want stuff that works.
Re: Speed
On Fri, Feb 04, 2011 at 01:29:02PM +, Richard Porter wrote: On 4 Feb 2011 Rob Kendrick wrote: As I said, you know where the sources are if you think you know better. Point noted but I think the 'dancing around' is more of a design problem. The problem is not as simple as you appear to think it is. The progressive relayout/reflow it does while fetching is there for good reason. And even if it weren't doing it, NetSurf would probably still be slower. Just because a page doesn't use any of the features NetSurf has that Fresco etc do not does not mean that the assoicated code is never executed, or data structures magically shrink, etc. In the future, NetSurf should be faster; we already have plans on how we're going to do that, and outlines for it all are on the development wiki. B.
Re: Speed
On 4 Feb 2011 Steve Fryatt wrote: Also, define any browser compatible. These days, I'd take that to mean lots of CSS and not Fresco-friendly; YMMV. What I mean is that they will format as intended on any browser (well maybe not early versions of mosaic) even if it doesn't support CSS or javascript. I am using css to enhance the appearance, but not things like position:absolute. If I use javascript there's always an adequate noscript element. That doesn't apply to third party software like Blah, though I haven't updated it beyond version 7 for compatibility reasons. -- Richard Porterhttp://www.minijem.plus.com/ mailto:r...@minijem.plus.com I don't want a user experience - I just want stuff that works.
Re: Speed
On 4 Feb 2011 Brian Jordan wrote: One thing occurs to me; you are using r11515 which is a development build of Netsurf which has with it a warning Notice: At any given time these builds may be unstable or have verbose logging enabled which could compromise performance of the browser, have you fallen foul of this? Maybe a comparison with the most recent release version might give a different result. Good point. I've run the tests with NS 2.6. The results were: test 1 - 48s (but 5s returning to the same page) test 2 - 19s (also 5s on return to the page). So the initial rendering is slower in 2.6 (much slower for the thumbnail index) but cacheing is a lot more effective. -- Richard Porterhttp://www.minijem.plus.com/ mailto:r...@minijem.plus.com I don't want a user experience - I just want stuff that works.
