Re: [cc65-devel] Binary loads of overlays on various targets

[<sil...@wf...>]

On 2013-05-28, at 11:39, Oliver Schmidt wrote:

> The CBM implementation of read() loops for each byte over calls to
> BASIN and READST. I see that this isn't going to be exactly fast ;-)
> The implementation of cbm_load() on the other hand just calls (SETLFS,
> SETNAM and) LOAD.
> 
> I'd appreciate if someone could give me some rough estimates about
> relative performance of these scenarios just to provide me with an
> idea of what we're talking about here:


That's a guesstimate of course rather than measured results.

> 1. read() with "default DOS" (let's define this as performance of 1.0)

1.0

> 2. cbm_load() with "default DOS".

2.5

> 3. read() with fast-loader.

Depends on fast loader. Software based fast loaders usually don't do anything to CHRIN (shall we change this "BASIN/BSOUT" to "CHRIN/CHROUT" eventually? ;-) and care only about LOAD. Better, hardware based ones do accelerate CHRIN operations too. Therefore:

1.0 (most software) - 9.0 (DolphinDOS)

> 4. cbm_load() with fast-loader.

10.0 - 80.0


As we discussed some time ago: if one has a LOADable chunk of data/mem dump to read, she should always try to LOAD it, as it gets faster in, in all cases. Saves efforts on the code side too. If the data to be read is not a kind of binary(or even textual)/mem dump but rather something that has to be processed upon reading (paradoxically, especially with large files), CHRIN is to be employed. At the cost of reading speed of course. An example:

In my disk imager I LOAD every binary (PRG) driver directly into memory, where it is going to be executed. But I CHRIN the preferences textual (SEQ) file, which I parse on the fly and set the parameters accordingly. Sure I could LOAD this one too and then parse from memory but I find it better not to. Because:

a) now I don't have to care where to put it for parsing (memory is at a premium)
b) since the file is user editable, I don't know what it will contain and how long it is going to be. LOADing it in some cases could cause overwriting things I don't want to
c) with CHRIN approach I have full control and I can read only as much as I need or want. If the user decides to include full King James Bible in the comments of the file, I can always tell him "sorry, buddy" without potentially crashing. I can also stop reading the file once I have all the key/values I need

-- 
SD!