Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
String parsing performance issue
Message
De
18/05/2001 17:16:05
Patrick O'Neil
American Specialty Information Services
Roanoke, Indiana, États-Unis
 
 
À
18/05/2001 17:11:23
Patrick O'Neil
American Specialty Information Services
Roanoke, Indiana, États-Unis
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Divers
Thread ID:
00508983
Message ID:
00508998
Vues:
22
>>I'm working on a project where I need to shred a string (ala shredding and XML string) into a set of tables. The string is passed to me by a call to an *.OCX. The typical length of the string is 43K+ bytes. The string structure looks like this:
>>
>>Data-Pair /pair delimiter/ Data-Pair /pair delimiter/ etc.
>>There are additional delimiters inside each data-pair. Essentially a data-pair consists of a delimited string that defines the schema and also separates the schema from the actual value. A Data-Pair ends up looking something like this:
>>Grand-ParentField/Delimiter/ParentField/Delimiter/Field/Value Delimiter/Value.
>>
>>My "parsing" engine works, but it's very slow. (About 2-3 seconds per string on a PII 300 Mhz notebook.) I need to get down to sub-second times without simply buying a faster notebook. I'm working on enhancements to make the string shorter. But I'm also looking for a way to more efficiently pass through the string as I shred it. That's what this post is for. So far the most efficient method of parsing the string is this:
>>
>>Do While .T.
>>DataPair = SubString( LongString, 1, At( , LongString )- 1 )
>>* Parsing code goes here
>>LongString = SubString( LongString, At( , LongString ) + 1 )
>>If Len( LongString ) = 0
>> Exit
>>EndIf
>>EndDo
>>
>>I've tried NextWord from foxtools, ( I'm running VFP 6 ) but it's actually slower than this approach is.
>>
>>Ideas anyone on a better way to work my way through the string?
>
>
>
>*------------------------------------------------------------------
>i haven't actually tried this solution, but intuition tells me
>that the string copy you do (LongString = SUBSTR(LongString...)
>is the bottleneck. i'm guessing that behind the scene, a character
>by character move is occuring.
>
>it would really be nice if AT had a fourth parameter that let
>you specify the starting position from which to begin searching,
>but it doesn't.
>
>instead of copying the remaining substring into LongString and
>getting your new piece by using SUBSTR with a beginning index
>of 1 ...
>
>keep the original string intact and keep track of a front pointer
>and a locater pointer, thus eliminating the copy operation on 43Kb.
>
>Total_Length = LEN(ALLTRIM(Long_String)
>Front_Pointer = 1
>Locater_Pointer = AT(,Long_String)
>WHILE ( Locater_Pointer > 0 )
> This_Piece = SUBSTR ( Long_String , Front_Pointer , Locater_Pointer )
>
> Front_Pointer = Locater_Pointer + 1
> Locater_Pointer = AT(,Long_String
>ENDDO
>
>
>interesting... think i'll put a timer around this and try it both
>ways.
>
>good luck.



oops ... please ignore that reply.
i assumed the AT function had the 4 parameter.
have you tried writing and calling a c function to the the AT ?
patrick
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform