Arc Forumnew | comments | leaders | submitlogin
6 points by kens 6114 days ago | link | parent

When I looked at benchmarking earlier (http://arclanguage.org/item?id=2455) I discovered that the performance hits were very different from what I was expecting. (I.e. in my case, it wasn't the function call overhead, but the < operator of all things.) My point is that if you optimize Arc, make sure you measure carefully, rather than assume you know where the performance goes. (I also found that performance is one of those things you're not supposed to discuss, a la http://www.paulgraham.com/say.html)

In my brief examination of the Arc internals, I didn't see any obvious optimizations. The ac-niltree/ac-denil stuff seems like there should be a better way. The conversion between nil and #f (e.g. ar-false? in your code above) seems like excessive overhead. But I don't see any better alternative.