Thanks for the trying Daniel, but as you said, this is probably not the best method to use in a distributed application. Hopefully Apple can help.
Performance running in iOS 5
(80 posts) (16 voices)-
Posted 6 months ago #
-
Good luck with that, Daniel! Apple is much worse than Microsoft when it comes to updates
Posted 6 months ago # -
Thanks, Kostya!
Well, I hope they simply say: add line XYZ here, and do some magic stuff there, and it will miraculously work again! *gg*Posted 6 months ago # -
I am not expecting it to be that easy from such a huge bueracracy machine that every big company is. But hopefully it will be fixed until we come to the beta testing of my games through Big Fish Games beta testers...
Posted 6 months ago # -
That makes a lot of sense! I was theorizing that the pool was growing too large for the iOS 5 memory management to handle well, and that's why it was choking. It uses the == equality operator to search for the bucket in the internal map (as per the == operator in std::pair), and if that == happens to check variable data of simply comparing pointer addresses, it will end up checking equality all the way to the end of the pool (Is mPoolPredecessor equal? Well let me check....is mPoolPredecessor's mPoolPredecessor equal? Well let me check...*cough cough help me*).
That also explains the leaks...well done Daniel!
Posted 6 months ago # -
So, Daniel, do you have anything from the Apple?
Posted 6 months ago # -
No, unfortunately there's no answer yet.
(Except an auto-generated mail that they have received my request.)Posted 6 months ago # -
I received an answer yesterday evening! So it took about a week for the answer, which is not too bad, I think.
More important is that they could indeed help me! The engineer who looked at it, Kevin, wrote that (as we expected) a change in the low level runtime (an optimization) caused the pooled object to end up in an invalid state.
He further wrote that, in any case (with or without the low level change), he thinks it's wiser to change the pooling approach slightly: not overriding the "dealloc" method, but instead both the "retain" and "release" methods (manually keeping track of the release count) and only calling the normal "dealloc" on the object when purging the pool.
That makes sense for me! I implemented the change right now, and it seems as if everything was back to normal. Perhaps some of you could try if it helps on your side, too!! (It's in the master branch, head revision.)
With that change, I gave it a test run, to see how the object pooling performs:
Without object pooling, creating and releasing 100.000 points took 0.376 seconds on my iPad 1. With object pooling enabled (and the pool filled up), the same operation took only 0.101 seconds! So it's definitely worth it, considering how many points, rectangles and matrices are created at runtime.
Posted 6 months ago # -
Excellent!! I will be delighted to give it a shot on Monday when I get back to the office :D.
Posted 6 months ago # -
Thanks Daniel!
I will give it a try in an hour or two and report back.
Posted 6 months ago # -
Problem gone, I am happy to report :). The stack trace looks much different now (in a good way). LookupBucketFor is down to 0.9%. Beers all around xD.
Posted 6 months ago # -
great news.. where can i get the repaired sparrow version? anyone can supply the hyperlink?
Posted 6 months ago # -
It is on github, the link is on the Sparrow download page. You can download it using Git, or just copy and paste from the github http page.
Posted 6 months ago # -
GitHub Project: https://github.com/PrimaryFeather/Sparrow-Framework
Direct Download: https://github.com/PrimaryFeather/Sparrow-Framework/zipball/masterPosted 6 months ago # -
thx borden n shilo.. do i just copy the files into my existing sparrow folder overwriting the sparrow 1.2 files there?
Posted 6 months ago # -
I suggest you either rename or delete the current Sparrow root directory, and just move the new directory in its place.
Posted 6 months ago # -
Thanks for trying it out, borrrden -- I'm very glad to hear that the fix was successful!
And thanks Shilo and Borrrden for helping out with the links -- sorry for not adding this information in the first place ...
Posted 6 months ago # -
Thanks for the fix!
Posted 6 months ago # -
Question: Which version of Sparrow is fine for production use? I'm still on the 1.2 tag, which was in May. I understand the head revision in GitHub is great for testing... but should I be deploying that in my AppStore games? Will there be a 1.3 tag coming soon that is blessed by the Primary Feather as production ready (with the ios5 fixes)?
Thanks.
Posted 6 months ago # -
Hi Ron,
you can safely use the head revision for App Store games. In the 2-3 weeks directly before your release, I would stop updating Sparrow, and run all your tests with the same version. -- Even when there's a new official release in that time frame, I'd stick to the old one, just in case.
Nevertheless, I'll try to get out a 1.3 release soon, with official iOS 5 support.
I hope that helps!
Posted 6 months ago # -
hi daniel, what improvement is in 1.3 ?
Posted 6 months ago # -
That will be a rather small update, concerning mostly bugfixes and only small improvements. Major changes will come in Sparrow 2.0 then!
Posted 6 months ago # -
Really nice picture, very good paintings.Sweetheart's Timberland Slippers
Womens Timberland Classic Tall Boots
Beautiful pictures everywhere, never seen such good-looking. Here I have some very beautiful pictures.If you have the time, you can come to take a look.Posted 6 months ago #
Reply
You must log in to post.