I know several RISC OS users regularly use the CI builds and have had
issues with the disc cache. This is partly a request for assistance
and partly a warning.
I have recently changed the disc based caching to use fewer small
files. This change is not backwards compatible and will leave the old
In article 20150403111441.gb18...@kyllikki.org,
Vincent Sanders vi...@netsurf-browser.org wrote:
(2298.804881) content/llcache.c llcache_finalise 3352: Backing
store average bandwidth 128324035 bytes/second
Hells bells - you'll be lucky to a tenth of that speed on RISC OS
hardware and
Vincent Sanders, on 3 Apr, wrote:
[snip - cache bandwidth]
NetSurf 2696
RPi2 SDFS 6067 bytes/s
RPi2 Fat32FS 15220 bytes/s
Iyonix320252 bytes/s
A9home509265 bytes/s
VRPC W7 SSD 605771 bytes/s
--
David Pitt
cj, on 3 Apr, wrote:
In article 20150403111441.gb18...@kyllikki.org,
Vincent Sanders vi...@netsurf-browser.org wrote:
The bandwidth line will be about 20 lines from the end of the log
I restarted Netsurf with cache enabled on the Iyonix. Loaded up the ROOL
forum. Message came up almost
On Fri, Apr 03, 2015 at 01:30:14PM +0100, nets...@avisoft.f9.co.uk wrote:
In article 54ae82a927ch...@chris-johnson.org.uk,
cj ch...@chris-johnson.org.uk wrote:
I can see why RISC OS gets indigestion with the cache. Have just
deleted the cache on the Iyonix, and there were over 21,000
Vincent Sanders wrote on 3 Apr:
If you are feeling very adventurous you can report the bandwidth
achieved. This is a line in the debug Log file held in scrap *after*
the browser has been quit. The last line of the Log will read
something like:
(2298.806358) desktop/netsurf.c netsurf_exit
On Fri, Apr 03, 2015 at 12:48:39PM +0100, Jim Nagel wrote:
Vincent Sanders wrote on 3 Apr:
If you are feeling very adventurous you can report the bandwidth
achieved. This is a line in the debug Log file held in scrap *after*
the browser has been quit. The last line of the Log will read
I can see why RISC OS gets indigestion with the cache. Have just
deleted the cache on the Iyonix, and there were over 21,000
directories and over 19,000 files.
--
Chris Johnson
In article 20150403111441.gb18...@kyllikki.org,
Vincent Sanders vi...@netsurf-browser.org wrote:
The bandwidth line will be about 20 lines from the end of the log
I restarted Netsurf with cache enabled on the Iyonix. Loaded up the
ROOL forum. Message came up almost immediately that the cache
On 31 March 2015 at 16:44, Jim Nagel nets...@abbeypress.co.uk wrote:
These pages from local newspaper takes ages in the fetching-processing
stage, and then finally displays its text in a pane that is too narrow
to read.
I have now tried on the PandaBoard. Used random pages from the Daily
Mail site (not much content if you are not interested in celebrates!).
The first time I tried I fairly quickly ended up with the cache being
disabled - the logged average speed was not much over 100 KB/s.
However, I then reran
On Tue, Mar 31, 2015 at 03:44:06PM +0100, Jim Nagel wrote:
These pages from local newspaper takes ages in the fetching-processing
stage, and then finally displays its text in a pane that is too narrow
to read.
In article 20150403111441.gb18...@kyllikki.org,
Vincent Sanders vi...@netsurf-browser.org wrote:
If you are feeling very adventurous you can report the bandwidth
achieved. This is a line in the debug Log file held in scrap *after*
the browser has been quit. The last line of the Log will read
cj, on 3 Apr, wrote:
In article mpro.nm8dx001qojsl00l7.pit...@pittdj.co.uk,
David Pitt pit...@pittdj.co.uk wrote:
Hmm! My Iyonix did over three time better than that, and there was no
too slow message. My test piece was http://www.dailymail.co.uk because
that is a particularly heavy
J. F. Lemaire, on 3 Apr, wrote:
On 31 March 2015 at 16:44, Jim Nagel nets...@abbeypress.co.uk wrote:
These pages from local newspaper takes ages in the fetching-processing
stage, and then finally displays its text in a pane that is too narrow
to read.
On Fri, Apr 03, 2015 at 02:39:05PM +0100, cj wrote:
In article mpro.nm8dx001qojsl00l7.pit...@pittdj.co.uk,
David Pitt pit...@pittdj.co.uk wrote:
Hmm! My Iyonix did over three time better than that, and there was
no too slow message. My test piece was http://www.dailymail.co.uk
because
In article mpro.nm8dx001qojsl00l7.pit...@pittdj.co.uk,
David Pitt pit...@pittdj.co.uk wrote:
Hmm! My Iyonix did over three time better than that, and there was
no too slow message. My test piece was http://www.dailymail.co.uk
because that is a particularly heavy duty site.
OK. A lot of
In article 20150403131050.gq29...@platypus.pepperfish.net,
Rob Kendrick r...@netsurf-browser.org wrote:
On Fri, Apr 03, 2015 at 01:30:14PM +0100, nets...@avisoft.f9.co.uk wrote:
In article 54ae82a927ch...@chris-johnson.org.uk,
cj ch...@chris-johnson.org.uk wrote:
I can see why RISC
snip
I suspect much of the delay for small files is due to checking,
creating, and traversing directories!
The depth was chosen so it would work on poor-quality file systems that
only allow a handful of entries in a directory, such as FileCore :)
It is a shame that there is no
On Fri, Apr 03, 2015 at 03:13:17PM +0100, David Pitt wrote:
I also think NetSurf's performance is severely hampered by the slow
processors available to RISC OS.
No, the CPUs are perfectly adequately fast. A Raspberry Pi can do many
megabytes a second when running Linux. RISC OS's IO layer and
20 matches
Mail list logo
