File I/O performance

Chat about anything CX16 related that doesn't fit elsewhere
Stefan
Posts: 456
Joined: Thu Aug 20, 2020 8:59 am

File I/O performance

Post by Stefan »



18 minutes ago, TomXP411 said:




You might save some time by reading larger blocks -  maybe copying your I/O code to low RAM when the editor starts. 



Yes, copying the read loop to RAM is a good option if you like to avoid bank switching and improve performance. Possibly it's sufficient to copy the inner loop that's run for every byte, and accept that other parts of the read function that's run more seldom is in the other ROM bank.

I would not like to gain performance by not calling READST or reading the status byte (if that can be done directly in a safe way) for every iteration of the read loop.

 

kktos
Posts: 50
Joined: Wed Dec 09, 2020 4:32 pm

File I/O performance

Post by kktos »



On 1/15/2021 at 3:55 AM, TomXP411 said:




I was curious how fast the Commander can actually read files from disk, so I fired up the emulator and did some quick tests. 



I wrote a very simple assembly routine that lives in Golden RAM (the section at $400), and timed it to see how fast it ran. 



With a 32K file, it takes 155 ticks, or 2.58 seconds. That makes file read throughput 12.7KB/s. 



Hum... not ok with your figures.

I took your asm with a 32K file and using the internal ticks counter, I got for the asm part only: 27 502 015 ticks.

That means for a 8MHz cpu :

27 502 015 / 8 / 1000 = 3437ms ~ 3.44s which make ~ 9.52KB/s

I did it again with a little change on your code in order to check how many bytes were read

image.png.3a7f8174fe3c4a4c7dcf147848dda92d.png

No suprise as I got $8000 bytes read.

It took around 3.47s

image.png.082f5a7e282b2dc38f09b3214bb56677.png

Now if I try to do the same without the old C64 kernal layer, calling directly the fat32 code, I got a sligthly better figure ?

image.png.720bb98f6e0f04edddaea3634fdbe32c.png

 

Post Reply