• 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: Repetitive Appending of Strings
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Repetitive Appending of Strings


  • Subject: Re: Repetitive Appending of Strings
  • From: Andrew Merenbach <email@hidden>
  • Date: Tue, 12 Feb 2008 10:21:25 -0800

Hi, Glenn and John,

I have a better idea of what I'll need to do now. I get the feeling that, since the only method call in the loop is the line in question, that will be the slow part. When users try to output hundreds of thousands of digits (not really that useful, most likely, but something which I feel should be supported -- if only for completeness), it might be a good idea to use a buffer, yes.

But I will try Shark and see what it says about the actual time involved in my loop.

Many thanks to you both!

Cheers,
	Andrew

On Feb 12, 2008, at 10:10 AM, John Stiles wrote:

If this is outputting a single digit per iteration of the loop, it seems like an extremely simple, effective optimization would be to allocate a buffer of "scale+1" bytes and then write one byte into it per loop iteration, specifially "q + '0'". You can't get much faster than that.

Then at the end of the loop, append a zero terminator to your buffer and you've got yourself a C string buffer with a number in it. You can easily convert that to an NSString with a single method call.


glenn andreas wrote:

On Feb 12, 2008, at 10:47 AM, Andrew Merenbach wrote:

Hi, all,

I have been working on a program that displays an extended output for a division equation, which involves a loop that continually appends a string, based on a number, to a longer string that is displayed to the user at the end of the process. My algorithm for everything past the decimal point (out to a number of digits determined by the variable "scale") looks like this:

       for (n = 0; n < scale && !self.isCancelled; ++n) {
           b = 10 * (b - q * a);
           q = floor(b / a);
           [quotientString appendFormat:@"%i", q];
       }

Note that call to -appendFormat. This is a beautiful solution in terms of simplicity, but for long outputs it's calling a method repeatedly.

What are my options here? The most simple optimization would involve using an IMP and creating a function pointer to a method, yes?


First of all, use Shark to determine if this really is a problem - no point in wasting time optimizing something that isn't taking a noticeable portion of your programs time.


One possible approach is to use an array of components and then combine them all together:

NSMutableArray *parts = [NSMutableArray arrayWithCapacity: scale];
for (n = 0; n < scale && !self.isCancelled; ++n) {
b = 10 * (b - q * a);
q = floor(b / a);
[parts addObject: [NSString stringWithFormat: @"%i",q]];
}
[quotientString appendString: [parts componentsJoinedBySeparator:@""]];


Not sure of this will be faster or slower - again, without using Shark to determine the bottlenecks, it's unclear if this will help.


But can people localize their numbers, thus rendering the unichar option insufficient due to its lack of ability to be localized easily? or am I missing an obvious solution for the unichar method, which -- if it's more efficient, and also sufficient -- I'd really like to use?


Yes, people can localize their numbers, but IIRC, you won't see any difference for this specific case (i.e., the %i format looks the same everywhere) - it's only once you get to floating point number (which you'll have to handle upstream in your code) or formatters that things get special. Fortunately, integer numbers are pretty standard (indo-arabic numbers 0..9 are understood pretty much everywhere - while various forms of gematria and other number forms can be used in certain places, I'm not aware of any localization that requires them).

The ultimate question is what are these numbers that you are using? If they are standard floats, doubles, or long doubles, why not just specify the precision with the built in formatting strings - they will do a better job than you can. If these number are something like a C++ numeric package for extended range numbers, said package probably also has a formatting command - again, with higher capabilities than what you're doing here.


Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
quadrium2 | build, mutate, evolve, animate | images, textures, fractals, art



_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Repetitive Appending of Strings
      • From: glenn andreas <email@hidden>
    • Re: Repetitive Appending of Strings
      • From: John Stiles <email@hidden>
References: 
 >Repetitive Appending of Strings (From: Andrew Merenbach <email@hidden>)
 >Re: Repetitive Appending of Strings (From: glenn andreas <email@hidden>)
 >Re: Repetitive Appending of Strings (From: John Stiles <email@hidden>)

  • Prev by Date: Re: NSStatusItem setHighlightMode throws NSInternalInconsistencyException on PowerPC ONLY (Works on Intel)
  • Next by Date: Re: Repetitive Appending of Strings
  • Previous by thread: Re: Repetitive Appending of Strings
  • Next by thread: Re: Repetitive Appending of Strings
  • Index(es):
    • Date
    • Thread