in reply to Re^3: Speeds vs functionality
in thread Speeds vs functionality

Is there any reason stopping you for keeping the parser state as a persistent C struct?

Correct me if I am wrong: currently, the state is keep exclusively on the Perl side and the cache is a (ugly) hack to be able to regenerate the C struct faster.

Why don't just store the state on the C side and keep it as a pointer inside a IV? That's what most XS libs do and I am sure it would improve the parser speed a lot, and at the same time simplify the code!

Are the module users allowed to modify the object hash directly?

Replies are listed 'Best First'.
Re^5: Speeds vs functionality
by Tux (Canon) on Jul 31, 2014 at 09:38 UTC

    I am keeping it as a cache, because the user is allowed to alter the behavior of the parser between parses. And that is useful. I also agree that the cache-dealing code has by now grown out to a horrid state, and I was already playing with the idea of replacing it with a single PV that holds a memcpy of the csv struct (which might need some extending then).

    In earlier days, the end user was allowed to alter the hash. I now only allow (reliable) changes through the method calls. That implies that I in theory can move all code to XS.

    I however am not yet sure if that would simplify the code, though it probably will :)


    Enjoy, Have FUN! H.Merijn