Dont ask what is faster, better to learn how to profile your code for yourself. When you will profile actual project, instead of microbenchmarking functions, you will learn much more from target performance and how to optimize real bottlenecks.
Afaik, most important thing here is not call speed, but GC speed/pressure. The less you allocate, the better for stable framerate, for example.
To alloc less objects (structures/arrays/strings/boxed types), you can use object pooling (keep and reuse dead objects), learn about incremental GC feature and even make your function inline, so it will generate x/y/z variables in place, instead of object allocation (this approach also has some drawbacks, like no inline method inherence or bigger binary size if inline things too long, but this can help in many cases). And if you dont need to call some method a lot every second, you can think more about better api, and not call performance.
Also, classes has faster field access than structures on some static targets (you can migrate things easily with @:structInit meta), but again, instead of theoretical changes, better to profile problematic code first.