optimalization

I asked because i did not know which level should I use?
I write only simple programmes, and I had some expiriences with AVR and I used there -Os optimalization.

I asked because i did not know which level should I use?
I write only simple programmes, and I had some expiriences with AVR and I used there -Os optimalization.

I write only simple programmes

Set optimization to Low or None. This will make debugging easier. This will also protect you from optimization level dependent bugs in your code. When you gain enough experience to not have to ask such a question, you can raise optimization level.
Good luck!

And I did cover this previously. If you write small and simple programs, then you do not have an explicit need for specific optimization. So you don't need to worry about your optimization setting. But lower optimization levels will make you happier when debugging.

I wonder if the level of optimalization have effect on speed in execute my program.
For example program in level 0 is faster then in level 3?

See level 0 as level "off".

But why are you wondering about speed, when you haven't shown that you have an actual need for speed?

Remember that with your previous processor, you all the time said "speed isn't important - I want small code". And now, you are suddenly wondering about speed from different optimization settings without firsts having found a project where you need extra speed...

You are lacking concentration. You need to put your focus on what is important. The important is what your device should do. And how to write code that does fulfill your requirements specification. First when there is a collision between what you manage to do, and what you need to do, will optimization be important.

You are right. I'm still thinking about AVR and I forgot that ARM is different

No. It doesn't work like that.

It isn't so much processor-specific as compiler-specific.

Bigger level means more optimization.

But more optimization does not imply smaller code. It just implies that the compiler will try more types of code rewrites when generating the output code.

And one way to increase the speed is to duplicate code. inline functions is one example - duplicating the code from a function body means that the call/return can be removed. And the need to copy a value into a register or push it on stack for the function call. And the need to clear the stack after the function returns.

In the same way, a short loop can be removed and be replaced with the multiple iterations placed after each other. This removes the extra tests (in case the loop always have a fixed number of iterations) and the extra jumps back to the start of the code again.

So while some optimizations (like identifying a common subexpression and computing the result only once) will result in smaller code. Some other optimizations will result in larger code. This totally irrelevant if you talk about an old Z80 or an AVR or a Intel i7 or anything in between.

Some other optimizations do not affect the code size. The compiler may rearrange the instructions to "hide" the memory access times by keeping the processor occupied with something else until a write or read finishes.

Obviously, the more creative the compiler is, the harder it will be to debug the code. You may look at the assembler output without being able to see how it matches your original C/C++ code. And when single-stepping, the debugger will jump up and down because the produced processor instructions are not grouped in the order of the source lines.
The documentation for the compiler might potentially tell a little bit about what optimizations that are added for higher optimization steps. But in many situations, you really have to test yourself. Both by looking at the generated code. And by looking at the size of the code. Then you may have to perform manual timing of the code to decide if the changes in code size and/or execution time is worth it for your specific critical code.

But if you haven't any critical code, then it's irrelevant to spend time thinking about these issues.

I'm still thinking about AVR and I forgot that ARM is different

That's got nothing to do with the issue at hand. You're still worrying about entirely the wrong things at this point.