ChangeFSI and !Scrap usage

I’m really happy with my new ‘old’ RISC PC.
It’s a strongarm one, so it’s fairly nippy – not as quick as the pandaboard clearly!
Anyway, after the wakefield show and getting various bits from both CJE and the charity stall – I’m underway doing some testing using !NewsUK and trying to tweak it more.
On my pandaboard using a RamDisc I get the whole lot loading in around 17 seconds.
However on the RISC PC, it takes just a smidging under 2 minutes.
One thing I notice is that on the RISC PC the hard disc light does flash, I assume that this is ChangeFSI is using the !Scrap directory somewhere.
But the input and output files in newsuk are both set to the ram area.
On the RISC PC I’m using RO 4.03 not 5.21 (this is deliberate, so I can test using the widest possible hardware and OS)

Tweaking it to allow ramdisc usage has moved the time from 2.5mins to 2 mins on a riscpc, but that’s still way off what I’m after.
(The pandaboard moved from 25 seconds to around 17)

Perhaps (well I know my targets are) my targets are unrealistic, but I would be hoping for a minute tops for loading on the RISC PC.

I’m not looking at doing any major rewrites now (I am planning some major work, but there is a lot of coding and modules to write for that), so has anyone got any suggestions to squeeze some extra juice?

FYI I am guessing after the rewrite it should load on the pandaboard in under 10 seconds, it’s a grand target to aim for I’ll admit. [my “internal” target is under 5, but I think I’m just being silly]

One thing I notice is that on the RISC PC the hard disc light does flash, I assume that this is ChangeFSI is using the !Scrap directory somewhere.

It depends what you’re asking it to do: some of the decoders (eg. btpc) are disc based, others always go via a file (eg. photo CD), others do not (eg. sprite) except if the input image is huge where it’ll be loaded in strips.

You could read up on the docs on the ChangeFSI system variables (in !ChangeFSI/Documents). There’s one to instruct ChangeFSI to cache the whole input if possible, though it defaults to 128k which sounds pretty big for a thumbnail image for a news article.

Yeah I’ve been looking at the docs there, I’m setting 128k anyway for that exact reason (so it is pretty much guaranteed that it fits in the memory). I’ll see if setting 1024k stops it and take it from there.
I’ve started looking through the docs more closely now and will be adding features (such as 32/16bpp and mode 28/greyscale and mode 15 options), for usage on a RISC PC, as it looks much nicer on my RISC PC when using mode 28 rather than attempting to display a 32bpp image, and there doesn’t seem to be any difference between 32 and 16bpp from what I can see on the thumbnails – which given their size isn’t a suprise.
Guess it’s dig, dig, dig ;-)

Seems It was a bit more obvious, !ChangeFSI was installed on the IDE disc.
Using a RAM disc for all the temporary files and moving !ChangeFSI onto RAM disc got the load time down to 1 minute 20 secs.
Not great, but better.