there might not be that many opportunities to optimize brainfuck programs as the instruction set of the brainfuck virtual machine is so simple. arithmetic is unary, and staying within the brainfuck virtual machine doesn't provide a way to do any better than unary arithmetic.

on another hand, there are many opportunities for optimization when compiling brainfuck to an actual real world instruction set

e.g. suppose in your program you want to load the integer 36 into the current cell

a naive way to do this is to increment 36 times, e.g. `++++++++++++++++++++++++++++++++++++`.

if you can't guarantee that the initial value of the current cell is zero, then you could zero it first: `[-]++++++++++++++++++++++++++++++++++++`

if we're optimizing for code size, not instruction count, we could express this as a more complex, compact program: `[-]>[-]++++++[-<++++++>]<` -- assuming it is OK to use the cell one to the right of the pointer as working storage. this will run slower than the less compact naive program as it executes more instructions.

if compiling to some reasonable instruction set, there's likely a single non-BF instruction that lets you load the constant 36 into a register.

extra credit: implementing the optimising brainfuck-to-something compiler in brainfuck itself