Performance Tokentext

While I have solved the problem now by using semanticParseData from within the semanticparser, I still would love to know if there is a faster way to access the tokentext...

When I implement a semanticParseData class that exposes a property like "Tag", why can't I write:
token.semanticparsedata.tag
?
Instead, I need to do it this way:
dim myclass as myparsedata
myclass = token.semanticparsedata
myclass.tag...

Is there a more straightforward way to do this?

[Modified at 06/01/2005 05:08 AM]

In the semantic parser's PostParse method you always know the range of offsets that were lexically parsed.

For your semantic parse data question, remember that .NET is strongly typed so it only knows that a SemanticParseData is an object with an interface that has no members. Instead of what you did, you can cast the data to your myparsedata type by using CType().

As for getting text, we use a StringBuilder in the background to store document text. So calls to our GetSubstring method actually have to do this: Note it's building a large string of the text buffer before returning the text substring. That's because StringBuilder has no Substring method on it. The indexer of the Document class calls the indexer of the StringBuilder directly.

One optimization we could try is seeing if it speeds things up to build the substring ourselves for GetSubstring, using the indexer of the StringBuilder as long as the length requested was under a certain amount. We had compared the method we use now with that strategy a long time back and ended up choosing what we did because overall it gave better performance. However maybe a hybrid approach would be best. We'll look into that.

But back on your topic... it might currently be fastest if you just grab Document.Text once before all your parsing and use the Substring method on that since that way you aren't constructing the string version of the Document's StringBuilder on every call to GetSubstring.

[Modified at 06/01/2005 05:48 AM]

very cool suggestion... I just tried it out, and it works 1000x faster... thanx! I now don't even need semanticparsedata as a means of caching any more...
By the way: your support here in the forum is excellent, it is a pleasure working with you guys!

We did some experimenting with various ways of storing/getting text substrings and the way we have it now is best. However if you are going to be doing a lot of substring searches on the same text, it is fastest to get the Document.Text, store it in a string and call the Substring method on that string like Tobias did. That will run faster than repeated calls to Document.GetSubstring.

Just FYI, we made a code change that will prevent you from needing to do anything special and should return substrings very fast now. It will appear in the next maintenance release. One user reported that on a huge document with lots of outlining parsing and token parsing, he did notice a visual difference in speed increase.

Thanks for the info.
I am pretty happy already with the workaround and will check whether your new approach parallels the speed or beats it... ;-)