Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance improvement with NSMutableString #3

Closed
JohnEstropia opened this issue Nov 22, 2013 · 4 comments
Closed

Performance improvement with NSMutableString #3

JohnEstropia opened this issue Nov 22, 2013 · 4 comments

Comments

@JohnEstropia
Copy link

You have an interesting library here. I think you can improve memory usage and performance by implementing categories on both NSString and NSMutableString. On the NSString category return [self mutableCopy], then on NSMutableString one call [self appendString:<letter>] and return self.

@coneybeare
Copy link
Member

Perhaps. I am not sure if this is actually going to be an improvement though because it all depends on how NSMutableString is implemented under the hood. If it is just a linked list of substrings, then perhaps it is an improvement. Feel like writing some performance tests?

If implemented this way, would need to return the class of string that was passed in. This way, if the implementer is doing any class comparisons on it, they would not get a surprise return. So that would mean doing a return [self copy] at the end which may negate the benefits of the performance bump. Thoughts?

@JohnEstropia
Copy link
Author

At the very least, using NSMutableString wont leave a lot of autoreleased objects. Though you're right, I also don't think there's a lot of use case for obfuscated strings anyway for this to matter.

About the class comparisons you were saying, wouldn't changing the methods to return NSMutableString instead be enough to state that behavior? Just to be safe, on the NSString category maybe instead of [self mutableCopy] just use [NSMutableString stringWithString:self].

Anyway I was just sharing some ideas. I have obfuscated strings as well, but with macros that XOR the characters out. Your method certainly looks cleaner though, so maybe I'll send a pull request when I actually have the chance to use it :)

@dominik-hadl
Copy link
Contributor

First of all, thanks for this handy category @coneybeare. I've been also wondering about the speed improvements when using NSMutableString, so I did some performance tests. All of the tests were run on iPhone 5 (iOS 8.0.1) and my Macbook Pro (OS X Yosemite). I'm showing only last pass of the tests on iPhone in this comment, but the results of all passes on both devices can be found at a Pastebin link below.

I made up some random strings, with various lengths and created the same strings using the category 5 times, each time measuring the time and new average of specific string. Here are the results when I used the category downloaded from Github without any modifications:

String obfuscation using non-mutable string approach

PASS NUMBER 5

# |   time   |   mean   | string
----------------------------------------
0 | 0.000020 | 0.000056 | abcdefg
1 | 0.000071 | 0.000143 | aide004791jdioadhjioaed43843
2 | 0.000120 | 0.000246 | abd43848 f6e48d348003c4384b43a438434e99767
3 | 0.000052 | 0.000100 | $a8 e897$ $56100$$d4
4 | 0.000088 | 0.000148 | .   .&DEPE!"5Oaop_%^

Now I modified the category, so it instead is a category on NSMutableString and all methods would return instancetype. All method implementations were changed to appendString: and then return self. The only difference then in my test code was that I had to change @"".a.b.c to [NSMutableString new].a.b.c for it to work properly (or you could maybe use mutableCopy). These are the results:

String obfuscation using mutable string approach

PASS NUMBER 5

# |   time   |   mean   | string
----------------------------------------
0 | 0.000016 | 0.000030 | abcdefg
1 | 0.000033 | 0.000073 | aide004791jdioadhjioaed43843
2 | 0.000076 | 0.000097 | abd43848 f6e48d348003c4384b43a438434e99767
3 | 0.000066 | 0.000068 | $a8 e897$ $56100$$d4
4 | 0.000069 | 0.000080 | .   .&DEPE!"5Oaop_%^

So as you can see, when using the category on a mutable string, it was 31% to 61% faster when creating the strings. I think this is a significant gain in performance.

I would be happy to make a pull request with the changes, however don't forget this will probably require a little change in how people use this category as it will have to be a NSMutableString which the methods will be called on. I will investigate if there is any option on how to preserve the same syntax as it is now (so you start with @"").

So, what do you guys think? :)

You can find all results (all passes & devices) on Pastebin.

@coneybeare
Copy link
Member

Wow, thanks for doing all this. Please send a pull request with the changes to start, then we can discuss more specific implementation in the comment threads for the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants