ooc translates to C, and as someone mentioned, it's often the C you would write yourself.
What you would really be benchmark here is Garbage collector vs vanilla malloc/free. And whether one or the other is fastest depends greatly on your scenario (and on your malloc implementation, e.g. http://goog-perftools.sourceforge.net/doc/tcmalloc.html is looking good)
Your statement "it's often the C you would write yourself" is a claim that you can support with numbers.
For example, in ooc you often have to choose between classes and covers. When you don't need inheritance, covers is often enough, + you get to work on the stack rather than all on the heap (in that respect, ooc offers more flexibility than Java, and a little less than C++)
What would also be interesting is offering abstractions for parallelism in ooc, etc. and then differences in benchmarks would show for "idiomatic" implementations. (Very much like Haskell idiomatic solutions are sometimes faster than C ones.)
The challenge that programmers are presented with nowadays is much more than just rewriting a few tight loops in assembler ;) Concurrency and parallelism are the most important challenges for us now, imho.
If you're interested in abstractions for concurrency and parallelism, I suggest you look at both Cilk and Apple's block extension for C (used in conjunction with Grand Central Dispatch). There are many others, of course, but those perhaps are the easiest fit into your language.