Re: Repetitive Appending of Strings
Re: Repetitive Appending of Strings
- Subject: Re: Repetitive Appending of Strings
- From: John Stiles <email@hidden>
- Date: Tue, 12 Feb 2008 10:10:55 -0800
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