Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
56 user(s) are online (43 user(s) are browsing Forums)

Members: 1
Guests: 55

Ami603, more...
Support us!
Recent OS4 Files
OS4Depot.net
Report message:*
 

Re: ftell() speed : newlib & clib2

Subject: Re: ftell() speed : newlib & clib2
by salass00 on 2019/9/26 10:50:10

@kas1e

The first two GetFilePosition() and the ChangeFilePosition() calls are from newlib's ftell() implementation calling fflush() at the beginning, which flushes any buffered writes and ensures that the file position is the same as the position in the internal read/write buffer (in your code this leads to the ChangeFilePosition() call to move one byte backwards because one extra byte had been read into the read buffer).

Clib2 also caches the current file position which means that the GetFilePosition() calls can be avoided, however it also means that any code that may directly or indirectly change the file position needs to keep this cached value up to date and valid or it can lead to buggy behaviour.

FWIW I'm currently looking into updating newlib to cache the file position in a similar way, which as I said above would at least make the GetFilePosition() calls unnecessary.

Another difference between clib2 and newlib is that newlib uses the newer DOS API calls with large file support, which means that it will be faster with new style vector port file systems such as NGFS and ram-handler but slower with legacy packet based file systems such as FFS2 and to some extent SFS which use packet packet based I/O and in FFS2 case probably does not even support the 64-bit packets leading to the first packet failing with ERROR_ACTION_NOT_KNOWN and DOS having to use a legacy packet as fallback.
Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project