Author Topic: NetSurf 3.6 web browser released! (Read 4725 times)

chris · « **on:** November 20, 2016, 02:47:08 PM »

NetSurf is a small fast web browser for AmigaOS and other platforms.

NetSurf 3.6 is primarily a bugfix release. It contains several fixes and clean-ups to front end code, as well as supercookie blocking, and certificate chain handling improvements. We recommend all users upgrade to NetSurf 3.6.

Download AmigaOS 4 version

There is also a preview/beta of NetSurf 3.6 for AmigaOS 3.5/9. Assistance is requested to bring this up to the standard of the OS4 build.
Download AmigaOS 3.5/9 version (pending upload approval)

utri007 · « **Reply #1 on:** November 20, 2016, 05:30:10 PM »

Congratulations for solving "slow down effect" of OS3.5/9 version

chris · « **Reply #2 on:** November 20, 2016, 06:55:43 PM »

Quote from: utri007;816634

Congratulations for solving "slow down effect" of OS3.5/9 version

Olaf Barthel's work, not mine

utri007 · « **Reply #3 on:** November 20, 2016, 07:19:49 PM »

Any change for optimisations to get lost speed back?

chris · « **Reply #4 on:** November 20, 2016, 08:21:45 PM »

Quote from: utri007;816637

Any change for optimisations to get lost speed back?

It's the price of eliminating memory fragmentation, I guess.

I believe that's as fast as it can be, any optimisations will be ones in the browser.

olsen · « **Reply #5 on:** November 21, 2016, 09:43:33 AM »

Quote from: chris;816638

It's the price of eliminating memory fragmentation, I guess.

I think that this warrants a thorough analysis. This the first time the new memory management system has been used, and we barely know enough about its real-life performance, let alone the constraints under which it operates.

I do not know what causes this slowdown, and I did not expect it either. Allocating and releasing memory should require (roughly) the same amount of time, regardless of the size of the allocation (as long as it can be covered by the allocator's page size). There must be more to that.

Quote

I believe that's as fast as it can be, any optimisations will be ones in the browser.

The new memory management (it's called a "slab allocator") is good at keeping fragmentation at bay. But we have barely begun testing it yet, it's hardly even a week old to begin with

There is plenty of room for "tuning" the new memory management. Tuning requires that data is collected on how the memory management is used, for later analysis. To this end there is an interface in the clib2 runtime library which NetSurf uses. It would be nice to allow for memory usage information to be collected through that interface, to be stored in log files.

chris · « **Reply #6 on:** November 21, 2016, 10:08:14 AM »

Quote from: olsen;816646

I do not know what causes this slowdown, and I did not expect it either. Allocating and releasing memory should require (roughly) the same amount of time, regardless of the size of the allocation (as long as it can be covered by the allocator's page size). There must be more to that.

@utri007 How much slower is it?

Quote

There is plenty of room for "tuning" the new memory management. Tuning requires that data is collected on how the memory management is used, for later analysis. To this end there is an interface in the clib2 runtime library which NetSurf uses. It would be nice to allow for memory usage information to be collected through that interface, to be stored in log files.

You can send SLABSTATS to NetSurf's ARexx port to get it to dump them to the log.

Code: [Select]

NetSurf -V ram:ns.log
rx &quot;address netsurf 'slabstats'&quot;

I did find with the log enabled NetSurf was crashing, but I don't think that's related to the stats collection. I might see about modifying this so the stats are stored in an ARexx stem variable.

This isn't in the 3.6 build as I added it later, I'll need to upload a new test version but I can't do that today.

I did notice that we get thousands of allocations of 32 bytes, and not much above 2K. I reduced the slab size to 2K (again, after this 3.6 build) and the timings don't look much different. v3.6 has the slab set at 8K.

olsen · « **Reply #7 on:** November 21, 2016, 10:32:18 AM »

Quote from: chris;816647

You can send SLABSTATS to NetSurf's ARexx port to get it to dump them to the log.
Code: [Select]
NetSurf -V ram:ns.log rx "address netsurf 'slabstats'"

Great! I'd like to see samples of these log files, if possible.

Quote
I did find with the log enabled NetSurf was crashing, but I don't think that's related to the stats collection. I might see about modifying this so the stats are stored in an ARexx stem variable.
I think log files should be stored in a format which makes automated analysis easy, e.g. JSON. I'll work something out.

Quote
This isn't in the 3.6 build as I added it later, I'll need to upload a new test version but I can't do that today.

I did notice that we get thousands of allocations of 32 bytes, and not much above 2K. I reduced the slab size to 2K (again, after this 3.6 build) and the timings don't look much different. v3.6 has the slab set at 8K.

Thousands of 32 byte allocations translates into hundreds of slabs. Worst case, allocation requires the traversal of the entire slab list to find that a new slab needs to be added. Deallocation likewise would (worst case) require a traversal of the entire list.

I think I ought to beef up the (not terribly sophisticated) slab statistics some more, so that the number of slab list items checked before an allocation/deallocation is performed is counted.

As for the list traversal effort, that says "hash table" to me

utri007 · « **Reply #8 on:** November 21, 2016, 10:33:36 AM »

Quote from: chris;816647

@utri007 How much slower is it?

Amiga.org is now 46-48 seconds first load. Going to forums and back to FrontPage takes 26-28 seconds each time. First pages were previously fastest 20-22 seconds.

Previously there wasn't that big difference when site is cached or not.

I'm happy to help, I can try this.

Quote

NetSurf -V ram:ns.log rx "address netsurf 'slabstats'"

chris · « **Reply #9 on:** November 21, 2016, 12:42:55 PM »

Quote from: olsen;816648

Great! I'd like to see samples of these log files, if possible.

I'll copy the file I have somewhere useful this evening.

Quote

Thousands of 32 byte allocations translates into hundreds of slabs. Worst case, allocation requires the traversal of the entire slab list to find that a new slab needs to be added. Deallocation likewise would (worst case) require a traversal of the entire list.

I was getting something like 800 slabs of 8K in total after visiting amiga.org.

Quote

I think I ought to beef up the (not terribly sophisticated) slab statistics some more, so that the number of slab list items checked before an allocation/deallocation is performed is counted.

Some sort of breakdown of size of allocations above the slab size might be useful too.

olsen · « **Reply #10 on:** November 21, 2016, 01:23:01 PM »

Quote from: chris;816651

I'll copy the file I have somewhere useful this evening.

Thank you! Please send it to me via e-mail.

Quote

I was getting something like 800 slabs of 8K in total after visiting amiga.org.

I'd say that this number is far too high. Which chunk sizes are most frequently-used? Scaling the respective slab size for these might be helpful and might work better in the long term than adding hash tables to speed up allocation/deallocation.

Quote

Some sort of breakdown of size of allocations above the slab size might be useful too.

Yes, this information is completely obscure right now. I'll have to change the data structure which tracks these allocations so that it no longer relies upon AllocVec(). The size information should become part of the management data structure.

yssing · « **Reply #11 on:** November 21, 2016, 03:29:33 PM »

Wau, thank you very much!

Netsurf is the browser I use most on my Sam440.

apj · « **Reply #12 on:** November 21, 2016, 11:11:48 PM »

Quote from: utri007;816649

Amiga.org is now 46-48 seconds first load. Going to forums and back to FrontPage takes 26-28 seconds each time. First pages were previously fastest 20-22 seconds.

Interesting, my version is now 2x faster on first load and 6x faster on reload on Amiga.org.
41s first load and 66s reload on old allocator. 22 seconds and 11s on new one.
Amigaworld.net 11 and 15 versus 9 and 8.

gregthecanuck · « **Reply #13 on:** November 22, 2016, 01:01:05 AM »

@olsen

Has the slab allocator from OS4 been back-ported to 3.x? Is that what you are testing?

Oldsmobile_Mike · « **Reply #14 on:** November 22, 2016, 02:31:48 AM »

Not bad! Haven't had a chance to play around with this for a while, I forgot what my settings were and just threw it on there, along with a copy of that guigfx.library it looks like it now needs.

1st load of amiga.org 35 seconds, reload in 21 seconds
Wikipedia
CNN
Google News

Attached a few screenshots.

I do wish that the minimize gadget worked, lol.

After I took these screenshots I tried playing around with some of the preferences. Nice that they work, I got a few visits from the guru but eventually was able to get it to open up on its own screen instead of of Workbench. Very nice! :banana:

Author Topic: NetSurf 3.6 web browser released! (Read 4725 times)

chris

NetSurf 3.6 web browser released!

utri007

Re: NetSurf 3.6 web browser released!

chris

Re: NetSurf 3.6 web browser released!

utri007

Re: NetSurf 3.6 web browser released!

chris

Re: NetSurf 3.6 web browser released!

olsen

Re: NetSurf 3.6 web browser released!

chris

Re: NetSurf 3.6 web browser released!

olsen

Re: NetSurf 3.6 web browser released!

utri007

Re: NetSurf 3.6 web browser released!

chris

Re: NetSurf 3.6 web browser released!

olsen

Re: NetSurf 3.6 web browser released!

yssing

Re: NetSurf 3.6 web browser released!

apj

Re: NetSurf 3.6 web browser released!

gregthecanuck

Re: NetSurf 3.6 web browser released!

Oldsmobile_Mike

Re: NetSurf 3.6 web browser released!