#bench marking

Aranca has created powerful frameworks and processes to optimize and transform businesses based on its experience as an external provider of technology scouting and bench marking services.  

View On WordPress

I have been working on an Android app for the past month or so and have come across a few really neat frameworks and tools to help Android developers design their applications for usability and performance. I would suggest checking out these resources (if you haven't already): http://developer.android.com/guide/practices/design/performance.html http://developer.android.com/guide/practices/design/responsiveness.html http://developer.android.com/guide/practices/design/seamlessness.html The final "tightening" of your application is crucial in order for it to be well recieved. In case you didn't know, the Android Marketplace user-base is quite vocal meaning they are not afraid to "tell it like it is". If your app isn't rock solid or doesn't perform well you should definitly read (or re-read) the above articles BEFORE you release! Tip: Use the Android Monkey tool. Upon my first run of the Monkey tool along side logcat I discovered a really nasty memory leak that would have been very hard to find (much less solve) late in the development cycle. Do yourselves a favor and release the monkey on your app today! Example Monkey command: $ adb shell monkey -p org.your.package.goes.here -v 500 Now I would like to introduce you all to the Caliper Microbenchmark framework http://code.google.com/p/caliper/ , http://code.google.com/p/caliper/wiki/JavaMicrobenchmarks . It is a completely free, open-source framework that feels alot like JUnit. Caliper is cool because it allows you to collect some statistics on your code performance. Read the second link to see some good reasons on why you would want to do this because I am to lazy to do so... Here is an example of a very basic perf test (pulled from Caliper's site): public class MyBenchmark extends SimpleBenchmark {   public void timeMyOperation(int reps) {     for (int i = 0; i < reps; i++) {       MyClass.myOperation();     }   } } Notice how the pattern is very much like JUnit. You create a test class that extends a test case (SimpleBenchmark). Here there is a difference being that we predicate the member function with 'time' instead of 'test' similiar to we do in JUnit. Additionally, we use a int parameter 'reps' to specify how many iterations we want our test to run for. Also notice the return type is void as it is with JUnit. At this point you may be wondering about private member functions. Maybe you have a really important private helper method that does alot of your applications work? Good, I am glad you asked! Fortunately the delvik JVM supports the use of Java's reflections library. Here is an example of using reflections to break encapsulation and bench your private methods: public class MyBenchmark extends SimpleBenchmark {   public void timeMyOperation(int reps) {     // the class object of the class we are testing     MyClass object = new MyObject();     Class reflectionsClass = MyClass.class;     // the method object we want to invoke during testing     Method myMethod = reflectionsClass.getDeclaredMethod("yourMethodNameGoesHere");     // DO NOT forget to do this...     myMethod.setAccessable(true);       for (int i = 0; i < reps; i++) {       // now we invoke the method using our test object!       myMethod.invoke(object);       }   } } Hopefully this code won't look too strange. I tried to make the example as straight forward as possible. If the Java reflections library is new to you, check out the API for it. It's really not that bad...I promise. If the outline below does not help, I suggest playing with reflections in a seperate test project. In a nutshell, this is what the above example does: 1. Create our object we want to test (object). 2. Get a class object of our test object (reflectionsClass). 3. Get the private method declaration we want to test (myMethod). 4. We reset the visibility of the method to public. 5. Invoke our method using the object we want to test with. I should also point out that the code above does not have the required exception handling for readability (this example actually needs to catch about 5 different exceptions). Furthermore, the simple act of invoking the Java reflections framework can add a bit of additional time complexity to your tests as well so you will probably need to account for this. Just be sure you check out the Caliper wiki pages and such to get an idea of what Caliper can do for you and what it cannot and also what you need to consider during these tests. Disclaimer: Please, please, please think of your API first and performance second...

WOO!

So, my advice to any other Meaties out there: Praise yourself once and a while. I mean, look at what you've accomplished so far! This all sounds a little self help-ish, but it really helps.

I only got 24 laps, but I was still getting used to the floor. That's my excuse and I'm sticking to it! Tomorrow I'll get the 25 for sure!