Message
From
28/06/2020 07:11:34
 
General information
Forum:
Visual FoxPro
Category:
Third party products
Title:
Miscellaneous
Thread ID:
01674989
Message ID:
01675038
Views:
214
>>Faststring.dll won't store its strings in VFP. You'll have to use FTRANSFORM(), FLEFT(), FRIGHT(), or FSUB() to return a string usable in VFP.
>
>I get that, but unfortunately I don't think that helps when retrieving individual values out because API calls (or FLL calls) have their own overhead in VFP. Have you done any performance comparison walking through a string with SUBSTR() compared to FSUBSTR()?
...
>Curious to see if what you've built here might address that although I'm not holding my breath due to the overhead of the API calls that may end up killing any native performance gains. That was my experience at least with the DECLARE DLL interface - maybe FLL is better there.
...
>Anyway - I'd be interested to see some benchmark comparisons between the native FoxPro functions and your replacements although I think Fox is pretty damn good with almost everything except SUBSTR(). I can't think of other scenarios where I've needed something to provide faster string support.

Mostly ACK. Lack of Array-like direct access to string elements worst aspect of vfp string handling.
Penultimate for me the lack of StringBu???er class/functions, forcing new memory assignment - most of the old dogs code long string results built from huge number of concats as pipe into LLF or array of smaller srings to build first, which then are concatenated at the end with few line calls each handling many array elements.

One edge case comes up for me: if you work with an array of tinyints and already have many fields, using a string as storage enables you to exceed field count limits on a record and avoiding another record just for such small helper fields. If you need 2 byte integers or larger, perf difference not as maked, but the runtime transform of asc/chr helps a lot.
I can imagine working on such a category group array via C faster, esp. if the string can stay locked in the C memory space for less work. Still something to both code AND call respecting C memory gotchas, as any error checking/trapping will beat the intent of max perf accomplished. As parameter passing is also a definite slow operation in vfp/fll, doing much work on a string set as "default" in C memory space might give a measurable edge.

Would be a messy API (simulating OOP setup and teardown via functions only) needing lots of docs and dire warnings

my 0.0022 (been a long time I needed to visit that machine room)
thomas
Previous
Next
Reply
Map
View