# BYOND: When Object Oriented Breaks Down

BYOND is an object oriented language.
BYOND also has a ton of overhead.

What does this mean?

Take, SSsounds, which we use on /tg/code.
It internally stores the 1024 free sound channels in an efficient datastructure for quick access.

This is custom coded.

Why are we not just coding, say, /datum/stack, initialized to 1 through 1024, and simply push and pop? That would be really simple, reusable, and **fast**, yes?

**No.**

Every function call in BYOND has overhead. BYOND does not inline anything.
Every variable access, including **global variables**, has a cost.

Our managed globals system incurs **two** accesses instead of one. The only reason we're using it is because we're busy cargo culting /tg/ and because managed globals can be easier to manage (by a slight, slight margin) and debug (although the folks over at Bay have written accessors for their ""unmanaged""-kindofmanaged globals, so that excuse is somewhat out the window too.)

If you want to write fast code for ridiculous and flashy features, accept that you'll be breaking some guidelines of how OOP works, and make life harder for yourself and others, **because there's simply no other way.**

- Lighting got sped up 10% by making an one line function a define
- We cache variables in procs instead of datumvars because that's faster to access.
- Sound uses a snowflake datastructure that would remind you of how computers allocate RAM instead of a linkedlist stack.
- Binary sorting is a #define, and even then, we **hate** sorting in BYOND!