Problem with mline approach is the minimum length for memline is 8 bytes. -------- Original message --------From: Ted Roche tedroche@gmail.com Date: 10/09/2016 21:41 (GMT+10:00) To: profoxtech@leafe.com Subject: Re: Processing a long character string one character at a time Hi, Joe:
Sorry, but my weekend is pretty full, so I can't answer as thoroughly as I'd like to. String functions in VFP are blazingly fast, but have to be used correctly in ways that aren't always obvious.
CSV with carriage returns inside fields is not CSV, in my not-so-humble opinion. ALL DBMSes have trouble with long text fields.
IAC, check out http://fox.wikis.com/wc.dll?Wiki~StringHandling for some clues. MLINE() and _MLINE against your string variable (I know it says it's about memo fields) is what you want, *I think*, but don't have time to check.
On Sat, Sep 10, 2016 at 1:32 AM, Joe Yoder joe@wheypower.com wrote:
I have a routine that processes each character in a file. The file I am working with is over 2 million characters long. I pull it into a memory variable with filetostr and then process each character with the substr command. Apparently substr has problems when dealing with a long string as the process is painfully slow.
I suspect that I will be better off using the low level file routines to read one character at a time but thought maybe someone knows of a way to speed up the approach I am using now.
Thanks in advance,
Joe
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]
_______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CACW6n4sNMe+yUXR=VhBdRU16HzhDeEDT9YyM... ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Report [OT] Abuse: http://leafe.com/reportAbuse/CACW6n4sNMe+yUXR=VhBdRU16HzhDeEDT9YyM+JDOgvttUQ...
Is it not an fgets moment ?
On 10 Sep 2016, at 13:08, foxdev foxdev@ozemail.com.au wrote:
Problem with mline approach is the minimum length for memline is 8 bytes. -------- Original message --------From: Ted Roche tedroche@gmail.com Date: 10/09/2016 21:41 (GMT+10:00) To: profoxtech@leafe.com Subject: Re: Processing a long character string one character at a time Hi, Joe:
Sorry, but my weekend is pretty full, so I can't answer as thoroughly as I'd like to. String functions in VFP are blazingly fast, but have to be used correctly in ways that aren't always obvious.
CSV with carriage returns inside fields is not CSV, in my not-so-humble opinion. ALL DBMSes have trouble with long text fields.
IAC, check out http://fox.wikis.com/wc.dll?Wiki~StringHandling for some clues. MLINE() and _MLINE against your string variable (I know it says it's about memo fields) is what you want, *I think*, but don't have time to check.
On Sat, Sep 10, 2016 at 1:32 AM, Joe Yoder joe@wheypower.com wrote: I have a routine that processes each character in a file. The file I am working with is over 2 million characters long. I pull it into a memory variable with filetostr and then process each character with the substr command. Apparently substr has problems when dealing with a long string as the process is painfully slow.
I suspect that I will be better off using the low level file routines to read one character at a time but thought maybe someone knows of a way to speed up the approach I am using now.
Thanks in advance,
Joe
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]
It could be a fgets moment, or a strtofile(). The problem is that Fox has at least three *different* solutions to string handling, depending on whether it's FPD, VFP-old or VFP-newer, and mixing them is asking for trouble.
Disk I/O pretty much doesn't matter any more, as everything ends up buffered in RAM for an operation like this.
On Sat, Sep 10, 2016 at 8:09 AM, Chris Davis chrisd@actongate.co.uk wrote:
Is it not an fgets moment ?
On 10 Sep 2016, at 13:08, foxdev foxdev@ozemail.com.au wrote:
Problem with mline approach is the minimum length for memline is 8 bytes. -------- Original message --------From: Ted Roche tedroche@gmail.com Date: 10/09/2016 21:41 (GMT+10:00) To: profoxtech@leafe.com Subject: Re: Processing a long character string one character at a time Hi, Joe:
Sorry, but my weekend is pretty full, so I can't answer as thoroughly as I'd like to. String functions in VFP are blazingly fast, but have to be used correctly in ways that aren't always obvious.
CSV with carriage returns inside fields is not CSV, in my not-so-humble opinion. ALL DBMSes have trouble with long text fields.
IAC, check out http://fox.wikis.com/wc.dll?Wiki~StringHandling for some clues. MLINE() and _MLINE against your string variable (I know it says it's about memo fields) is what you want, *I think*, but don't have time to check.
On Sat, Sep 10, 2016 at 1:32 AM, Joe Yoder joe@wheypower.com wrote: I have a routine that processes each character in a file. The file I am working with is over 2 million characters long. I pull it into a memory variable with filetostr and then process each character with the substr command. Apparently substr has problems when dealing with a long string as the process is painfully slow.
I suspect that I will be better off using the low level file routines to read one character at a time but thought maybe someone knows of a way to speed up the approach I am using now.
Thanks in advance,
Joe
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]
-
Chris Davis -
foxdev -
Ted Roche