Profiling and reflection

[Adam Jones]

I'm not sure how many people would be interested in this, it's
probably really basic information for someone who knows what they are
doing. After getting the basics of this game I'm working on up and
running I ended up spending a bit of time profiling it and eliminating
some reflection that was really impacting performance. I made a little
write up about it, which can be found here: http://blog.finiteimprobability.com/?p=27

-Adam

[Rich Hickey]

Thanks for sharing your experience. It seems there's one technique of
which you might not be aware. You can type-hint your defns, in
particular all the get-* accessors you have, and then not need to tag
every use.

(set! *warn-on-reflection* true)

(defn foo
"foo the thing into a string"
[x] (str x))

(let [f (foo 42)]
(. f (toUpperCase)))

-> Reflection warning, line: 67 - call to toUpperCase can't be
resolved.

(defn #^String foo
"foo the thing into a string"
[x] (str x))

(let [f (foo 42)]
(. f (toUpperCase)))

"42"

Also, type-hinting something on which you don't use member access (.)
is only useful for overload resolution, not performance. So declaring
#^PersistentHashMap data in render, and #float m etc in steer, does
nothing useful.

Combining these, I think the only type hint you would need would be
#^Graphics g in render.

Rich

[Adam Jones]

Great. I kind of went nuts with the type hints for a shotgun method.
Being able to declare a type for accessor function certainly would
help clean things up quite a bit. I've got plans for today, but I'll
update the post to reflect this as soon as I can so people aren't
getting the wrong impression.

-Adam

>
> Rich