So I have my old mytouch 3g with cyanogenmod 6 as my gsm phone when I’m on vacation. The slowness is unbearable. It turns out the key to getting excellent performance is the following.
- Under cyanogenmod settings go to performance settings
- turn on JIT (Just in time compiler for the Dalvik VM)
- uncheck enable surface dithering
- Check Lock home in memory
- Finally replace the default ADW Launcher with LauncherPro
This last step, replacing the home launcher with Launcher Pro is what really did it for me. Hope someone finds this useful.
My biggest gripe about Perl has always been the lack of functional prototypes and method signatures. The concept of method signatures is not a revolution it’s been around forever, almost every programming language I can think of off the top of my head has it in some form. Having to unpack @_ time and time again is just such a waste of keystrokes. Not only that there are multiple ways to do something so basic. (Shift, copy the list to lexical vars, direct access in $_[i] etc). It’s surely been the source of a number of bugs and something every Perl programmer needs to be conscious of.
My main argument for method signatures is it reduces bugs and it documents your code without having to write documentation. Its declarative, it does what it says and says what it does. Plain and simple no guessing. As most Perl programmers are aware Devel::Declare is a module that has added the ability to extend Perl 5 the language without source filters. There are several really cool modules that have been developed on top of Devel::Declare. MooseX::Declare and MooseX::Method::Signatures and Method::Signatures in particular. The first MooseX::Method::Signatures, comes bundled as part of MooseX::Declare. MooseX::Declare adds declarative class and method keywords on top of Moose. MooseX::Method::Signatures has it’s own type system and does optional run time type checking on arguments much like you would do with Params::Validate except with a declarative syntax. It’s down right beautiful and makes you warm and fuzzy inside to use it, the down side is there is a huge performance penalty to use MooseX::Method::Signatures at run time. Depending on what you are doing it might not matter much.
The module Method::Signatures gives you 95% of the sugar and 100 x performance over MooseX::Method::Signatures. Type checking at run time is something that I usually don’t need (This is still Perl, I swear). Positional and named parameters are both supported along with defaults and constraints. On my latest project I’ve been using Moose along with Method::Signatures and I couldn’t be any happier. Take a look at the performance benchmarks I’ve included comparing these two modules along with regular ‘sub’ methods.
MooseX::Declare bench code
use MooseX::Declare;
class Foo {
has x => (
is => 'rw',
isa => 'Str',
);
has y => (
is => 'ro',
isa => 'Str',
);
# I use the three vars below to ensure that the subs
# are not constant-folded away. Although I'm not sure perl will do that.
our $meth_counter = 0;
our $meth_without_args_counter = 0;
our $meth_typed_counter = 0;
our $regular_sub_counter = 0;
method method_with_type( Int $x ) {
$meth_typed_counter++;
$self->x . $x
};
method method_without_type($x) {
$meth_counter++;
$self->x . $x
};
method method_without_args() {
$meth_without_args_counter++;
$self->x;
};
sub regular_sub {
my ( $self, $x ) = @_;
$regular_sub_counter++;
$self->x . $x;
}
};
package main;
use Benchmark qw(:all);
my $foo = Foo->new( { x => "3", y => "45" } );
cmpthese(
300000,
{
method_with_type => sub { $foo->method_with_type(5) },
method_without_type => sub { $foo->method_without_type(5) },
method_without_args => sub { $foo->method_without_args() },
regular_sub => sub { $foo->regular_sub(5) },
}
);
MooseX::Declare Results
aaron@ ~/method_signature_bench $ perl MooseXTest.pl
Rate method_without_type method_with_type method_without_args regular_sub
method_without_type 5320/s -- -9% -12% -99%
method_with_type 5865/s 10% -- -2% -99%
method_without_args 6014/s 13% 3% -- -99%
regular_sub 612245/s 11408% 10339% 10080% --
Method::Signatures
package Foo;
use Method::Signatures;
use Moose;
has x => (
is => 'rw',
isa => 'Str',
);
has y => (
is => 'ro',
isa => 'Str',
);
our $meth_counter = 0;
our $meth_without_args_counter = 0;
our $meth_typed_counter = 0;
our $regular_sub_counter = 0;
our $regular_sub_without_args_counter = 0;
method method_without_type($x) {
$meth_counter++;
$self->x . $x
}
method method_without_args() {
$meth_without_args_counter++;
$self->x . '5';
}
sub regular_sub {
my ( $self, $x ) = @_;
$regular_sub_counter++;
$self->x . $x;
}
sub regular_sub_without_args {
my ( $self ) = @_;
$regular_sub_without_args_counter++;
$self->x . '5';
}
package main;
use Benchmark qw(:all);
my $foo = Foo->new( { x => "3", y => "45" } );
cmpthese(
300000,
{
method_without_type => sub { $foo->method_without_type(5) },
method_without_args => sub { $foo->method_without_args() },
regular_sub_without_args => sub { $foo->regular_sub_without_args() },
regular_sub => sub { $foo->regular_sub(5) },
}
);
1;
Method::Signatures Results
aaron@ ~/method_signature_bench $ perl MethodSignature.pl
Rate regular_sub method_without_type regular_sub_without_args method_without_args
regular_sub 579710/s -- -7% -17% -25%
method_without_type 625000/s 8% -- -11% -19%
regular_sub_without_args 701754/s 21% 12% -- -9%
method_without_args 769231/s 33% 23% 10% --
Analysis
These tests are not exhaustive nor do they need to be. Its clear that even with no arguments subs and Method::Signatures are on order of 100 times faster than MooseX::Method::Signatures. What really surprised me here is that Method::Signatures looks to be faster than subs. It would be an interesting test to benchmark the number and types of arguments.
Bottom line is I will use Method::Signatures and Moose in any new projects I write in Perl. I’ve been successfully running production code with Method::Signatures since September with no problems. Hoping to get some feed back on how Method::Signatures could possibly be faster than subs.
Note
- Benchmarks run on a Mac Book Pro with a 2.4ghz core i5 processor and 4b of ram
- Modules tested
I ran into some Safari related timing issues at work, that I thought were worthy of a post. To preface the post I’m using the dojo framework. On to the post…
I needed to position a flash overlay relative to the absolute postion of a div that will vary in position on subsequent page loads. So in comes the handy dojo.coords(id) function wrapped in a dojo.addOnLoad. This works like a charm in firefox 3, ie 6, ie7 and google chrome. In safari, no dice. The offsetTop and offsetLeft calculations were completely off (I tried this with my own custom function as well as dojo.coords()) I was finally able to get this to work with using a setTimeout delay (hack).
After researching the issue it seems apple decided to make window.onload fire “before” the page loads. (Seems counterintuitive to me, but it’s no wonder it’s so fast in benchmarks) This explains the miscalculation of element positioning on the page. Waiting for the page to load with a timeout fixes the problem. The solution is a hack and is obviously not fool proof as in there is no real barrier to execution. Does anyone in the interweb out there know how to get Safari to fire onload as in when the page actually finishes loading? Knock knock.
September 21st, 2009
aaron
After one month with the MyTouch and Android there are a few things I see as road blocks to being a real competitor to the iphone. Some of these things are definitely being addressed in the upcoming 1.6 and 2.0 os updates.
First off is the market store. It’s strictly bare bones. The search and category breakdown is not developed enough. For instance when you search, you can’t search subcategories. Your search is run across all applications, leading to many false positives. Product pages for apps don’t have screen shots etc. This will change shortly with the 1.6 donut release.
Next on my list is multi-touch. It’s scheduled to be part of the 2.0 release which may or may not be here before Christmas. To really be a worthy competitor to the iphone this is a must have. It’s overdue.
On to a few not so obvious or talked about gripes. There’s no desktop equivalent to itunes. I think an itunes equivalent was a major oversite on behalf of google. Itunes makes managing your media on your phone and desktop simple. This would be even more evident if you purchase music on your device through itunes. After purchasing music there is no automatic synch up from your amazon purchases to an itunes equivalent, becaue it doesnt exist. When I used itunes I tended to purchase through itunes on my desktop and synch to my ipod.I think others largely do the same. Lets say to be fair that 50% of people would be more inclined to purchase through their desktop app. Google could potentially open up sales of mp3′s and apps by 50 %. Ok maybe I’m off and its 25%. Thats still 25% of a growing market.
Ah yes theres more. The performance is sluggish at times. This could be related to a host of issues. Most likely some kernel tuning will be done in future android releases. How about google set up a paid service where they test and certify applications and mark them as google tested and verified. It would add a level of quality control that users would be able to discern.
A real media player. The media player kind of stinks. It doesn’t pickup album covers 95% of the time, and there is no way to add them after the fact. How about a genius playlist feature similar to itunes? Nada. Its pretty primitive.
Of the things I listed the following are definitely being addressed, multi touch, the app store and performance . The media features seem to be a bit of an after thought with android. By focusing on the app store, media features and performance google and partners stand to pick up business from disgruntled iphone users.
MyTouch 3G
I’ve been resisting and resisting getting an iphone for two years. Mainly because while I know its a fine product, I see Apple as a controlling company. I liked the open nature of android but passed on the G1 because the hardware was pretty uninspiring. I finally gave in as soon as tmobile released it in July. So far so good. The android market is chock full of applications. Some great and some not so great. Pluses of the phone are the integration with all things google, including their awesome calendar. The web browser is very usable. However it would be nice to have multitouch. Supposedly there is multitouch support already built in to the kernel. The omission was due to google not wanting to upset apple. They do have a symbiotic relationship so it makes sense. However, with Apple pulling Google Voice from the apple store, I wouldn’t be surprised to see multitouch sooner than later. Other things of note are the decent battery life and excellent reception.
Many of the apps could use more work, the facebook application doesn’t provide the ability to upload images. The trend is upwards though. There are many many android phones being released in the next 6 months. Along with that will be more developers developing applications. I’m going to explore the SDK and post about it.
I use eclipse for various programming projects and really, really miss having vim key bindings. I stumbled across this eclipse plugin that does just that. Most of the basics work like seaching, jumping to line x with :, matching braces with %, jumping to the beginning and end of a line etc. Couldn’t ask for more. There is a license fee of around 20 dollars which to me is worth it, otherwise an annoying popup appears after periods of inactivity.
http://www.viplugin.com/viplugin/
December 11th, 2008
aaron
Watch out Hopstop! I wrote a Graph lib in python along with heuristic hSLD A* search and brought it to life with google maps and Ajax. The library is running as a json-rpc service with mod_python. The next step is to use geocoding api to turn street addresses to lat and lon coordinates and integrate it to find starting and ending stations, fun fun fun.
Maybe Ill put this on google app engine if I get alot of hits.
http://www.dancygier.com/nycsubway
Categories: Python, Software development Tags: googlemaps, javascript, new york, nyc, Python, route, route finder, route planner, subway, subway directions
When did soap and perl become so difficult. Using it as a server is a complete pain. SOAP::Lite was cutting edge 5 years ago. Its just a bit behind with the evolving wsdl standards. So I decided to use XML-RPC, its all I really need and interopability with other languages should be simpler. This is the main reason why I’m using web services to begin with.
Speaking of the XML RPC cpan modules. RPC::XML works well but the documentation is lacking. You have to putz around to get anything to work. add_method() is especially poorly documented. Much guessing and the perl debugger helped me get the syntax correct:) It would be great if there was Apache2 integration … But I shouldn’t complain it actually works and works well.