The Icon Bar: IrisRam speeds up Iris

Posted by Mark Stephens on 07:44, 30/11/2022 | Software

If you are using the Iris browser, there is a nifty new utility called IrisRAM to speed up the software.

There is a very clear readme telling you how to install the software (make sure you have a ramdisc, copy IrisRAM onto your machine and run on startup). What IrisRAM does is to copy Iris (which you need to have installed separately) into RAM disc. IrisRAM will check several locations to find your copy.

This makes the machine takes slightly longer to start (it needs to copy the software across). But you can then load and run it from RAM (which is quicker). How much quicker will obviously depend on what machine you are using.

You can also add a shortcut to your desktop to run Iris directly from RAM.

You can get IrisRAM for free from the same place you download Iris (curently last updated May). It adds just a little bit more speed and polish so definitely worth giving it a try.

IrisRam speeds up Iris

nunfetishist (10:23 30/11/2022)
  arawnsley (16:49 30/11/2022)
    Bucksboy (18:42 30/11/2022)
      arawnsley (11:40 1/12/2022)
        richw (19:43 1/12/2022)
          arawnsley (23:38 3/12/2022)
            richw (20:20 4/12/2022)

Rob Kendrick

Message #125368, posted by nunfetishist at 10:23, 30/11/2022

Today's phish is trout a la creme.

Posts: 525

If copying the app to a RAM disc speeds its day-to-day running rather than just its start up, that suggests it's writing data to its application directory: very bad practice!

It should be using !Scrap, !Cache, !UnixHome, etc.

[ Log in to reply ]

Andrew Rawnsley

Message #125369, posted by arawnsley at 16:49, 30/11/2022, in reply to message #125368

R-Comp chap
Posts: 600

Or it could be in beta and using local copies of resources (eg. fonts/cache) so as not to pollute working systems with cutting edge alpha/betas which could then be difficult for users to diagnose/remove. Just sayin'

Most of the performance elements are related to loading of the shared libraries and font caching. AFAIK those elements are still ahead of the versions offered via riscos.info and therefore could conflict if users updated working versions with newer Iris versions. Emphasis on "could". But better safe than sorry when delivering test-version software.

Actual browser cache, choices etc are stored in !Boot.Choices.WWW.Iris as you'd excpect.

[Edited by arawnsley at 16:53, 30/11/2022]

[ Log in to reply ]

George Greenfield

Message #125370, posted by Bucksboy at 18:42, 30/11/2022, in reply to message #125369

Member
Posts: 91

I'm currently running Iris from Memphis, where it lives permanently. Would IrisRAM benefit me?

[Edited by Bucksboy at 19:15, 30/11/2022]

[Edited by Bucksboy at 19:16, 30/11/2022]

[ Log in to reply ]

Andrew Rawnsley

Message #125371, posted by arawnsley at 11:40, 1/12/2022, in reply to message #125370

R-Comp chap
Posts: 600

Not really - I was going to add Memfs support to IrisRAM but I didn't have a copy to hand, and IIRC Memfs allows you to save ram disc contents anyway, which would achieve the same thing.

The only "extra" that Iris does is to ensure system variables point to the right place, and add it to Apps (resourcefs) with instructions on how to ensure the RAM based version can be on your pinboard (there's a boot-order thing to tackle).

IrisRAM doesn't do anything that a user couldn't do themselves, but it does so in a neat/attractive manner, with documentation etc.

[ Log in to reply ]

Richard Walker

Message #125372, posted by richw at 19:43, 1/12/2022, in reply to message #125371

Member
Posts: 73

It's a bit mad that this sort of thing exists. It seems to me that there are two real problems:

1. Iris having its own, incompatible, copies of 'shared' resources. I sort-of understand why this has been done, but isn't the real root cause here a reluctance of many old farts to embrace package management?

2. Typical RISC OS disk I/O performance isn't too hot.

Would be nice if those nuts were cracked, but I appreciate that I am not in a position to do 'em, so I should probably stop there - if not earlier!

[Edited by richw at 20:20, 4/12/2022]

[ Log in to reply ]

Andrew Rawnsley

Message #125373, posted by arawnsley at 23:38, 3/12/2022, in reply to message #125372

R-Comp chap
Posts: 600

Richard, you may be right on 1) [I am an old fart for sure!] but I'm not sure how package management solves the issue of (potentially) incompatible alpha/beta libraries and font system / cache.

We'd need to design some kind of sandboxing system, otherwise there'd be problems.

At least I *think* we would - I'm genuinely asking for clarification, not trying to be silly-smart. I'd value your thoughts / opinions.

One thing I do know is that whilst people like to point fingers/laugh at how we've handled this in Iris, if you look to other platforms, it is now quite common to sandbox stuff in Docker containers or (on Linux, via package delivery systems) use things like FlatPack. These pretty much do exactly what Iris does (provide all the resources in the app/package, self contained), but perhaps in a slightly more joined-up manner.

So, what can we learn here - I'd welcome thoughts on this (genuinely) because I'm out of my comfort zone in that area.

One thing I 110% agree with you on is that we need working disk caching of some description ASAP, and ideally with the flexibility of specifying when to use write-back, and when to use write-through. That'd make a huge improvement to large apps with heavy disc use.

Without that, having a more "integrated" Iris (ie. less sandboxed) would actually make getting IrisRAM-like speed into a huge nightmare because copying all the different parts into RAM for speed purposes would potentially be much larger, and more problematic (because we can't know what other apps might be expecting/impacted).

As I say, thoughts welcomed

[Edited by arawnsley at 23:44, 3/12/2022]

[ Log in to reply ]

Richard Walker

Message #125374, posted by richw at 20:20, 4/12/2022, in reply to message #125373

Member
Posts: 73

I'm no expert, and just thinking of my use of 'packages' and 'package managers' on other platforms. For example, Android App Store, iOS App Store, Node Package Manager (for front-end web development), Nuget packages (for Microsoft .net development), and 'apt' in various Linux distributions.

I've never had issues with them. You just select the software you want, and it installs, including any dependencies. It also keeps itself up to date. Brilliant.

I know in RISC OS land, people like to have lots of different versions of the same thing floating about (e.g. Zap), and offered up on all sorts of 'home pages'. And then people like to get obsessed over where exactly stuff lives on their hard disk.

Since Acorn started making suggestions with the 1994 Risc PC disk structure, I've just found it easier to go along with it. Don't fight it. Same with the other package managers on other platforms: just let stuff go where it will. Don't sweat it.

I agree that a shared component needs to be compatible with other things using it, so we cannot have breaking changes. Isn't that business as usual, though?

If Iris needs some exciting new packages releasing, then maybe those just need releasing? Then an Iris package will 'just work'.

I don't think the platform is big enough to need incompatible libraries: the list of apps and developers is so small, can't we just play nice?!

P.S. I certainly wasn't thinking of you as an 'old fart', Andrew!

[ Log in to reply ]