Thread 107166228

void func()
{
A* a = new A();
a->foo();
A z;
z.foo();
}

Assuming foo is not virtual and ignoring allocator overhead, why might z.foo() be faster than a->foo?

You should be able to solve this

Cache miss. Next thread.

>>107166249
>Cache miss
Incorrect sar and good morning

>>107166228 (OP)
because it's calling it rather than searching for it?

Cache hit. Next thread.

>>107166535
Incorrect, now show bobs n vagene

>>107166228 (OP)
>Assume
>ignore
How about no?
Also the answer is because it's in the stack

>>107166228 (OP)
because heap management isnt free

>>107166228 (OP)
do you homework on your own ranjeesh

>>107166888
The heap can be as fast as the stack, and in this case it is.

>>107166228 (OP)
sounds like bullshit
it's the same call
maybe if z.foo() is inlined into func, there's some extra optimization that can be done on the resulting code, but that still sounds like bullshit

>>107166228 (OP)
not a pointer? idk I am a vibecoder now

I am disappointed that /g/ isn't as smart as a YouTube jeet

>>107167557
Unlikely because the allocation's cacheline may not have been cached before the function entry. It's however almost a given that the top of the CPU stack (whatever is in RSP on x86-64 for instance) is already cached.
This is a retarded question anyway due to an optimizing compiler generating whatever the fuck it wants.
>>107169448
The jeet actually has to try. This board is just hobbyist NEETs.

stack vs heap

>>107166228 (OP)
both types of method invocations pass a pointer to the called function
you were wrong yesterday, and you are wrong today

Heap allocation takes an eternity in CPU time compared to moving the stack pointer

>>107170444
that's like a single instruction vs 10 instructions

>>107170543
Syscall you retarded jeet

>>107170790
it's only a syscall if sbrk() gets called, which should be extremely infrequently