• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Fastest/smallest search+replace
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fastest/smallest search+replace


  • Subject: Re: Fastest/smallest search+replace
  • From: Ali Ozer <email@hidden>
  • Date: Mon, 14 May 2001 14:01:10 -0700

> My personal opinion is to do in straight C. Get a cString from the
> NSString. Create a char[] the same size as the origional string. And
> just run through the entire origoinal cString, appending each character
> to
> the new char[] one at a time unless they are an '\n' character. This,
> aside from doing the same in assembly would be very fast.
>

You need to watch out though, because getting a cString might fail
(return NULL) if there are encoding conversion issues.

I have four variations of this
1: a one-line version (componentsSeparatedByString /
componentsJoinedByString)
2: my original (posted before)
3: my original but with a 1000-char temporary buffer, avoiding the
autoreleased substrings
4: one in terms of cStrings (converting the string to UTF8, and assuming
targetString is just one char)

My timings are:
10000 line doc; 1 replacement per line: 0.29s, 0.15s, 0.09s, 0.13s
60000 line doc; 1 replacement per line: 3.9s, 0.81s, 0.61s, 0.45s
60000 line doc; 4 replacements per line: 7.2s, 2.5s, 1.4s, 1.2s
200000 line doc; 1 replacement per line: 45s, 2.8s, 2.0s, 1.5s

So the cString version (the 4th number in each row) is faster, but not
significantly so, especially from the NSString one with the
autoreleasing removed from the internal loop (the 3rd number). The
simple-minded one-line version of the code (1st number) breaks down as
the doc gets larger, as it has high memory usage.

Note that the last row represents a ~3000 page document...

In any case, looks like this might be good functionality to include in
NSString.

Ali


  • Follow-Ups:
    • Re: Fastest/smallest search+replace
      • From: Marco Scheurer <email@hidden>
    • Re: Fastest/smallest search+replace
      • From: "John C. Randolph" <email@hidden>
  • Prev by Date: SIGSEGV/SIGBUS in java cocoa app using NSComboBox and NSTableView
  • Next by Date: Re: Volume Tracking in Cocoa without Carbon?
  • Previous by thread: Re: Fastest/smallest search+replace
  • Next by thread: Re: Fastest/smallest search+replace
  • Index(es):
    • Date
    • Thread