Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!news.albasani.net!.POSTED!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Good Fowler article on ORM Date: Sat, 12 May 2012 12:27:26 -0700 Organization: albasani.net Lines: 63 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net 87go9OgWP8aFcIxF8J3mhQq5XPwAC7Pya5pL75LNKbPYgx1PYCcNtO7STCSNy4AOxrhegi/HsTxl2UIbg4iz5BZb5p9N0MCXzsPN5pZRIX7PIGPYsovvXeW6Ean/zZYC NNTP-Posting-Date: Sat, 12 May 2012 19:27:24 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="O7g6VCZWVDKrrN67O9GAX4eXUJS0XG2A39a5YAIjxkOA+jYyAP0nL5TVHh5IzWl0euLqcYf5CPz7ZfIGOi8KlEYBMdKawYqHAYrCVUl8DXtOCsgOgXsPc1PH+CddROFW"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 In-Reply-To: Cancel-Lock: sha1:YHMIsujD6+9+zk+UAIm6YTfqiqw= Xref: csiph.com comp.lang.java.programmer:14492 markspace wrote: > Jan Burse wrote: >> markspace schrieb: >>> Just curious: I've never done an Android development. How does one >>> profile code for that environment? Do you have a Dalvik JVM that runs >>> on Windows/Unix (i.e. an emulator of some sort)? Is there a good >>> profiling tool that can attach to certain Android devices? >> >> I guess there are some tools around. Android has its own >> way of instrumentation for tracing. >> http://developer.android.com/guide/developing/debugging/debugging-tracing.html > > Good link, thanks for posting that. > >> But I did not yet use it. Was just benchmarking my App and >> saw that it runs much slower on Android. But that has also >> to do with that I was using a tablet with something of 1GHz >> ARM and was comparing against a 3.4GHz 64-bit Intel. Oh, really? You think that just might have a teensy-weensy little bit to do with the performance difference, just maybe? I've worked a bit with Android code and deployment environments here and there. No question, you have to be rather conservative of resources in Android, but it's at the platform level for the most part, not the JVM level. I am highly dubious of the claim that accessor/mutator time was the major determinant of the putative performance issue. Android deployments suffer from platform limitations - Jan mentioned one, the slower ARM vs. the customary wideband desktop, usually multicore. The programming model differs, too. Android is more like a Xen or other virtualized meta-OS, with each Dalvik a different virtual host. So things move in and out of memory differently - think of old-fashioned memory overlays - than they do on the desktop. Applications move in and out of memory on Android at the whim of Android, not Dalvik. You do have to bear this in mind as you write for Android. For example, you have to be ready to resume your application from a total shutdown at any instant, even just to change orientation. You're far more bound to the UI than you might be used to. Your GC is clunkier than Java SE's, and you sort of do have to watch your RAM, and more importantly, your threads. But RAM on a typical Android device ranges from a quarter gigabyte up. We're not talking microwave-oven controllers, here. These are quite literally pocket supercomputers. 1 GHz is slow? Come on! Another factor is logging. Android has a syslog called "logcat", to which everyone, their cousin and the family dog contributes. That surely affects performance, and it makes it interesting to find your own log data amidst all the noise. How many of you are good at designing log output? Liars. Of the ones who did not raise their hand, about half likely are good at it. That's why they don't claim to be. The other half have a hope to be someday. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg