The Mobile SDK Code is Painfully slow, and needs to employ a methodology that makes it run faster

[#1]

The code really needs to employ a different methodology that will make it faster.  Even when following best practices, there are requests getting fired off at every turn and it really slows applications down.  The code should use a different approach, like holding on to all of the requests in a log file and then sending them off at times that will not impact performance.  The methodology of the Google SDK is may better from a performance perspective.  I've worked at multiple organizations on multiple apps with many, many developers who would like to use Omniture for mobile, but can't because of how much slower it makes their applications.

[#2]

The 3.x SDK's are highly performant have been since last May when they were released. The SDK handles all the threading and we've tested it with over 2000 concurrent threads with no degradation on the device CPU. If you have some data points on performance of the 3.x level of the SDKs, please send them over to me at rjwoods@adobe.com. We've benchmarked the SDK's against many other analytics SDK's in the market and we're highest performing in terms of speed to send 100 hits, least impact on the device CPU, and highest quality of data sent automatically with all the lifecycle metrics sent in the launch hit. Are you using old SDKs? You can always get the latest here: https://developer.omniture.com/en_US/content_page/mobile/c-measuring-mobile-applications Also, the mobile app team carries a zero bug count on the SDK's and fixes issues in the next MR. You can see the comments on the download pages for the SDK and the release notes of the changes in each release.