Honestly, the performance mentioned in the manual is ambiguous at best and downright dangerous at worst.

Firstly, every function in there, not including blocking I/O operations, is blazing fast. Most will execute in the nanosecond area with some maybe taking up to a microsecond. By themselves, you will never ever notice any kind of performance hit from calling them. What matters is context, you can very well write code that performs incredibly bad despite only using functions marked as "fast", if you deliberately, or unknowingly, play against the CPUs branch predictors and pre-fetchers. And of course you can do it the other way around as well, writing code that only uses "slow" functions which achieves much much better performance by tweaking it so that the generated code plays perfectly with the CPU and is ordered in such a way that it has the maximum throughput you can get.

The thing is, context matters. A lot. You really ought to ignore the performance remarks in judging how fast your code will be, because 99% of the time, it will be blazing fast. If your game runs slow, get out a profiler to see what actually takes the time and then optimize these hotspots. Everything else is just wasted time.

And most of the time that "hotspot" will be rendering.
if your game is a relatively small project and unless you do something immensely stupid you will probably hit gpu bottlenecks long before cpu bottlenecks. And that will also probably be something stupid or unecessary(too much polygons or complex effects for scenery fillers/small props, missing lods etc. or I/O can cause hiccups when loading large shit on runtime)