Gunzip for MSX

페이지 11/11
4 | 5 | 6 | 7 | 8 | 9 | 10 |

By wouter_

Champion (418)

wouter_의 아바타

12-11-2015, 20:13

Louthrax wrote:

I'll try to use Wouter's version for SofaUnZip 1.1. The 10% speed gain and smaller memory usage is definitively super-interesting.

Thanks. If you need any help just ask.
One thing that might not be obvious at first sight is that you need to re-initialize some global variables when going from one file to the next. This (re-)initialization was explict in Grauw's version because there you destruct and re-construct various objects.

By wouter_

Champion (418)

wouter_의 아바타

12-11-2015, 20:26

Grauw wrote:
syn wrote:

I wonder of the limit has been reached yet (speed-wise)?

Pretty much. Aside from statically allocating the objects as Wouter has done, I don't see much more opportunity for optimisation.

That's always a dangerous claim to make. When I first read your comment I thought you were probably right. But only a few hours later I've improved my code by 3s. Thanks Prodatron!
I'm also out of ideas at the moment, but who knows what else will turn up Smile

By hit9918

Prophet (2867)

hit9918의 아바타

12-11-2015, 22:43

Does zip store filelengths in headers? Then one could just check the length instead doing the full CRC.
The default mode on MSX could be only integrity check on headers.
I long time havent seen corrupt files anymore.
diskettes are gone and "the net" too no more makes corrupt files.
Maybe the most common case of file "corruption" is things like when the server starts talking html, saying "error".
That is no corruption with one bit flipped, it is no zip file at all.

Also check whether you catch all kinds of "disk IO error" on the MSX file API side.
A location where corrupt files would happen.

By Grauw

Ascended (8442)

Grauw의 아바타

13-11-2015, 02:28

wouter_ wrote:
Grauw wrote:
syn wrote:

I wonder of the limit has been reached yet (speed-wise)?

Pretty much. Aside from statically allocating the objects as Wouter has done, I don't see much more opportunity for optimisation.

That's always a dangerous claim to make. When I first read your comment I thought you were probably right. But only a few hours later I've improved my code by 3s. Thanks Prodatron!

Smile

Yeah, gonna try that one as well! Hadn’t expected there’d be much to gain in the CRC part, because I have been staring at it for so long Smile.

hit9918 wrote:

Does zip store filelengths in headers? Then one could just check the length instead doing the full CRC.

It does, and it already checks, it does make disabling CRC verification a little safer because with the Huffman compression the odds are high that corruption changes the file size.

But only for large files the difference is really noticeworthy. And if you’re just occasionally extracting a file, who cares about waiting a few seconds more. So I’ll leave it to users to take the risk, to make a conscious choice to disable CRC verification with a command line option when it really saves them valuable time, I don’t think it should be disabled by default.

By Grauw

Ascended (8442)

Grauw의 아바타

21-11-2015, 05:00

Though they are uncommon, I sped up the processing of uncompressed blocks (they occur when you gzip an already-compressed file), those are now processed twice as fast.

By Grauw

Ascended (8442)

Grauw의 아바타

27-12-2015, 19:44

Interesting factoid; disabling interrupts speeds up decompression by 13.8% (87s -> 75s).

Of course, ctrl-c stops working and even if I worked around that, who knows what else, so I’m a bit hesitant to disable them. Maybe only in /f mode…

By Daemos

Paragon (1671)

Daemos의 아바타

27-12-2015, 20:33

what about reading only ctrl and c right from inthook and skip the rest of the BIOS inthandler during decompression?

By Grauw

Ascended (8442)

Grauw의 아바타

27-12-2015, 21:10

The solution I would opt for is to replace these lines:

    call DOS_ConsoleStatus  ; allow ctrl-c

with

    ld a,1
    ld (SCNCNT),a
    call 38H
    call DOS_ConsoleStatus  ; allow ctrl-c

And disable the VDP ints with the IE0 flag. The ISR should account for irregular calling anyway (e.g. during disk I/O), so I guess it would be fine like this.

(Setting SCNCNT to 1 to force it to rescan the keyboard every time rather than every fourth ISR call.)

By Louthrax

Prophet (2080)

Louthrax의 아바타

27-12-2015, 22:36

Quote:

Maybe only in /f mode…

I would make it a separate option (for people having background music or whatever TSR app... ?).

By Grauw

Ascended (8442)

Grauw의 아바타

27-12-2015, 22:43

Well, background music would fail horribly anyway due to the disk I/O also disabling interrupts for extended periods of time, as well as anything else that really relies on regular interrupts. I mean in essence disabling VDP interrupts while doing a (relatively) infrequent manual call would be indistinguishable from heavy disk I/O. So if the TSR already has to be tolerant for that, I think it should also be able to handle this…

Another example of something that runs commonly on the timer interrupt is the disk drive motor control, it waits X interrupts before stopping the drive from spinning to reduce the number of spin-ups and spin-downs… that also wouldn’t be an issue here.

페이지 11/11
4 | 5 | 6 | 7 | 8 | 9 | 10 |