Re: Interesting Experiment With String/Sequence Slicing
- Posted by Derek Parnell <ddparnell at bigpond.com> Aug 21, 2001
- 428 views
Robert, is the *ANY* chance (pretty-lease) that you might create an in-built version of match and find that allows a starting offset index, similar to BASIC's instr() function. Maybe somthing like ... findfrom(offset, look_for, look_in) matchfrom(offset, look_for, look_in) I find myself frequently cutting and dicing slices, or doing ssllooww searches because this functionality is missing. It would be so much faster if these were in-built rather than Euphoria-written functions. ----- Original Message ----- From: "Robert Craig" <rds at RapidEuphoria.com> To: "EUforum" <EUforum at topica.com> Sent: Wednesday, August 22, 2001 2:00 AM Subject: Re: Interesting Experiment With String/Sequence Slicing > > > Sam Lie writes: > > i have ran the profiler and the bottle neck still > > shows up when doing string slicing. > > I gather from your earlier private e-mail that you are reading huge > strings from a file and running match() on them. > Or perhaps the string *is* the whole file? > > Since match() starts at the beginning of a sequence, > and stops when it encounters a match, I gather > you are slicing the 50K strings to look for further matches. > > Try reading and searching one line at a time using gets(). > You won't be copying a huge string when you have a match, > and you'll make better use of the Pentium on-chip cache, > e.g. > object line > integer fn > > fn = open("myfile.html", "r") > while 1 do > line = gets(fn) > if atom(line) then > exit > end if > if match("foobar", line) then > ..... > end if > end while > close(fn) > > After doing the above, if you are still convinced that > slicing is the culprit, you could write your own match() > that locates multiple occurrences without slicing. > (There may be an example in the mailing list archives.) > > Regards, > Rob Craig > Rapid Deployment Software > http://www.RapidEuphoria.com > > > > > > >