How to speed-up access to strings

[Ricardo de Mila]

Dear Bytes comunity...
I'm trying to speed-up the way I'm interacting with big strings.
I have an string with more than 2M caracteres and would not like to use the function mid$ to read, and change a specific character.
I'd like to use VARPTR or STRPTR, but I could not understand how to access the memory to get the content of a character directly.
Could somebody give me some help?
Best regards
Ricardo

[cactusdata]

What would "speed up" mean?
This runs in 0.15µs where s is a string of 2 mio. characters:

Mid(s, 10 ^ 6, 1) = "x"

[NeoPa]

Hi Ricardo.

Your question is pretty unclear. What do you mean by using the Mid$() function? This is the only function that I can think of that is used both on the left AND on the right of the =. On the right it may make sense. On the left? Not so much.

Also, you introduce two terms - VARPTR and STRPTR - but give nothing to indicate where you got them from. I was able to determine they're both hidden members of the VBA library, but only in more recent versions.

My suspicion here is that they're there to allow you to see where the data's stored, but the absence of any way to use that to manipulate the data is very deliberate.

I suspect you just need to explore using the Mid() function on the left of the = in your code. It should do all you need.

[ADezii]

Just as a side note, to the best of my knowledge, Mid$() is more efficient than its counterpart Mid() when dealing with Strings.

[isladogs]

Just as a side note, to the best of my knowledge, Mid$() is more efficient than its counterpart Mid() when dealing with Strings.

Interestingly, I was going to reply that Mid$ is now largely obsolete, along with Left$, Right$, LTrim$, RTrim$, LCase$, UCase$, but all can still be used for backwards compatibility. Am I wrong in that belief?

[Rabbit]

The purpose of the PTR types are to be used as pointers to be passed to API calls. VBA itself doesn't deal directly with pointers and has no way of dereferencing the pointers to get access to the memory. If you want to manipulate memory with pointers, you'll have to do it through an API call. But that isn't necessarily faster than using the built in string functions.

[NeoPa]

Rabbit:
The purpose of the PTR types are to be used as pointers to be passed to API calls.

Thank you. That's very helpful info, and it makes total sense where I was struggling to see any.

ADezii:
Just as a side note, to the best of my knowledge, Mid$() is more efficient than its counterpart Mid() when dealing with Strings.

You may be right there but I've not heard that.

I do know that, while the $ versions of those functions are still supported, because they have general usability limitations when compared to the non-$ versions, they are no longer recommended. Essentially they're only there to support the existing code base. I find it very hard to imagine that any reduction in performance would even be detectable over hundreds of iterations so while it may be possible, I certainly wouldn't worry about it. The recommendation from Microsoft, going back many years now, is to use the versions that return Variant values so the caller can handle results where no string value can be returned.

Essentially, that would indicate that IslaDogs' understanding is correct.

[ADezii]

I`ve always had a preference for Functions that return Strings rather than Variants (NULL returns excluded), thus avoiding the Data Type Coercion factor. Does that make sense, or am I too, obsolete? (LOL).

[isladogs]

Of course ADezii$ is an exception to the rule regarding obsolescence :~>).

[ADezii]

Nice! Out of curiosity, when I get a chance, I'll run Benchmark Tests using both Versions of the Function, although I am fairly sure as to what the end result will be.

[SioSio]

I've posted code that compares speeds using Mid, Mid$ InStr, InStrRev Replace functions, and Regular expressions.
In my PC environment, the results show that Replace is much faster than Mid.
but the administrator decides it's not relevant, I removed it.

[NeoPa]

Hi SioSio.

Have you posted that in the right thread? I can't see where it answers the question or otherwise adds to this discussion. Am I missing something?

[NeoPa]

ADezii:
I`ve always had a preference for Functions that return Strings rather than Variants (NULL returns excluded), thus avoiding the Data Type Coercion factor.

I'm not sure that there would be any Data Type Coercion involved - even with the Variant returning version. If you assign a String value Variant to a String variable then it just assigns. No coercion required. In fact, I'm pretty confident that any coercion for one version would be matched by the other. I can't think of any exceptions.

IslaDogs:
Of course ADezii$ is an exception to the rule regarding obsolescence :~>).

Quite right :-D

He may have an extraordinary fondness for archaic versions of some functions but we love him anyway. Few of us have been around on Bytes.com longer than he and I suspect few are as well loved. His eagerness to volunteer his time for all & sundry is legendary.

[SioSio]

The sample code I showed was a function that could specify the start address of a character variable in memory and the length to retrieve. In other words, this function behaves the same as the Mid function in memory. However since it was pointed out that the problem was not solved, I deleted the post.

[cactusdata]

But you asked for faster alternatives to Mid.
Will this run a replacement in your large string faster than 0.15µs?

PS: Mid$ runs at exactly the same speed as Mid.