[Hecl-devel] Performance

[Simon, J. <jon...@qu...>]

Hi All.

First, I want to thanks everyone who's chimed in here. Now that the list issue got solved last night, I've got a small Proof of Concept up and running fully integrated in my application. Hecl is definitely an easy way to write ME scripts, and the connecting logic with the commands and operators is very straightforward to write. I didn't really focus on style for this POC, rather I just built commands and operators as seemed logical while paying only a little attention to performance or memory overhead.

That said, I started doing some performance analysis yesterday and I wanted to start quick discussion on command/operator implementation styles and ways to improve performance. Basically, my analysis was showing something like a 10x increase in execution time from the native Java to Hecl. Now, I know that it's definitely going to be slower to run a client side interpreter. My goal now is to see how low I can get that increase by tweaking my commands/opeators and code style.

Taking a step back, I also want to reiterate that I'm not trying to use Hecl as a full scale replacement of ME code. Rather, I'm building something of a host ME application that contains all of our authentication and net connection logic, as well as a custom data model. I'm using hecl more "inline" to replace the Views and Controllers in my application. This way, we can send new logic to the phone - but again, we're only scripting what we absolutely need to.

As a result, I noticed I ended up doing A LOT of casting and a I'm using A LOT of ObjectThings to pass objects to Hecl from the commands and then strip those objects out of ObjectThings for commands that use them. For reference, I developed a UI framework in ME built on top of Canvas that's similar-ish to Swing called Sangria. So I created a Sangria operator that builds and returns ObjectThings with components in them:

private Thing create(Thing[] args) {
String stringRep = args[1].getVal().getStringRep();

if ("screen".equals(stringRep)) {
                        return new Thing(new ObjectThing(new SScreenBase()));
} else if ("container".equals(stringRep)) {
                        return new Thing(new ObjectThing(new SContainer()));
            } else if ("label".equals(stringRep)) {
                        return new Thing(new ObjectThing(new SLabel()));
            } else if ("textArea".equals(stringRep)) {
                        return new Thing(new ObjectThing(new STextArea()));
            ...
}

>From there, I built a number of commands to manipulate these objects and set information on them from the model. I ended up with a lot of code like the following to then strip the components out of ObjectThings:

private Thing addToContainer(Thing[] argv) {
            SComponent component = (SComponent) ((ObjectThing)argv[1].getVal()).get();
            SContainer container = (SContainer) ((ObjectThing)argv[2].getVal()).get();
            container.addComponent(component);
            return null;
}

Like I said though, the amount of casting and object transfer has to be a huge performance bottleneck though I haven't checked the extent of this specifically. However, the code is very straightforward to write. It feels declarative for sure, but once these commands were built, it was really easy to convert my screen creation code to hecl.

As for alternatives, I first attempted to create a builder class during prototyping, but I abandoned that since this syntax was just so much easier. However, with performance as a consideration, I think the app could be sped up a lot without the excessive transfer of Java objects back and forth through ObjectThings and casting.

Does anyone have any thoughts here? Should I go down the builder path again? Any other suggestions or places to look for good command design and inspiration?

Sorry I can't paste more code. If I need to I can isolate the POC code, but it's been useful to do the work embedded in my actual application to see how it functions. I can definitely isolate the code and possibly post it somewhere if anyone is interested in a more in depth discussion of command design and general architecture.

Thanks!
-jonathan

Jonathan Simon
Staff Engineer

Firethorn, a Qualcomm company

Four Concourse Parkway, NE

Suite 475

Atlanta, GA 30328

www.firethornmobile.com<http://www.firethornmobile.com/>



CONFIDENTIALITY NOTICE: This e-mail, including any attachments, has been sent for the sole use of the intended recipient(s). It may contain information that is confidential and proprietary. The confidential and proprietary status of the information is not waived by having been sent by e-mail transmission. If you are not the intended recipient, you are not authorized to review, disclose, copy, distribute or use any of the information contained in this transmission. If you have received this e-mail in error, please notify the sender by reply e-mail and purge all copies of this message. Thank you.