[physfs] Replace malloc/strcpy by strdup
Christoph Nelles
evilazrael at evilazrael.de
Thu Sep 30 05:20:57 EDT 2010
On Thu, 30 Sep 2010 09:04:36 +0200, Tolga Dalman
<tolga.dalman at googlemail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/29/10 18:59, Christoph Nelles wrote:
>> Am 29.09.2010 17:58, schrieb Tolga Dalman:
>>> Perhaps, it might be an idea to get rid of dynamically allocated
>>> path strings, and use arrays instead ? This might vastly improve
>>> performance at cost of memory, I suspect.
>>
>> That is a good idea, but to support old C standards resp. compilers you
>> have to declare them at the beginning of the blocks, probably wasting
>> memory if unneeded. A problem might be maximum length of paths. Systems
>> have a maximum path length MAX_PATH (or PATH_MAX?) and this might be
>> exceeded by virtual paths with utf-8 characters in it. So you would
have
>> to limit it or stick with dynamically allocated memory.
>
> You are talking about variable length arrays ? I.e:
> struct S {
> /* other variables */
> char buf[];
> };
> This is also possible of course, but also prone to programming
> errors to my experience. I was rather talking about stack arrays of
> fixed size.
Then you didn't understand me.
> Most operating systems have a limit on the maximum path length anyway
> AFAIK. PATH_MAX is at least 255 according to POSIX and 1023 according
> to SUSv2. On modern Linux this limit is at 4096 bytes, but I don't know
> about other OSes.
Yes. But Physfs has no maximum file name length. And even if you take a
system limit you would have to multiply the string length as Physfs allows
UTF-8 encoded file names which can be much longer.
> Using stack arrays instead of heap-allocated memory is often worth the
> memory waste due to better alignment, no indirect calls, less memory
> fragmentation etc.
> However, without a proper PhysFS benchmark, we can just speculate about
> any numbers.
Write your own one. Some nice portable benchmark will be appreciated.
Do some things, use a profiler, look for the worst stuff, tell us/me about
your findings.
I postulate that the cost for this memory allocation is neglectable in
comparison to the cost of the real I/O. So, i'm out of this discussion.
Nether the less, a good benchmark would be interesting.
--
Christoph Nelles
E-Mail : evilazrael at evilazrael.de
Jabber : eazrael at evilazrael.net ICQ : 78819723
PGP-Key : ID 0x424FB55B on subkeys.pgp.net
or http://evilazrael.net/pgp.txt
More information about the physfs
mailing list