2

A global variable is allocated in the data segment, while a local one stays in the stack. I know that accessing a variable stored in the heap is slower than accessing a local variable, but I don't know if accessing a local variable is faster than accessing a global one. Does it depend on the compiler? Are the differences significant or not?

pro-gramer
  • 166
  • 1
  • 3
  • 14
  • 1
    Whether your first question is even true depends on the compiler and target platform. –  Oct 14 '16 at 08:02
  • 1
    If there is any difference, it is probably insignificant. – Jabberwocky Oct 14 '16 at 08:07
  • Stack, heap and the data segment are in the same memory. Anything of the specified could be paged away by the OS. So how exactly reading from one memory address could be faster than reading from another? – Ari0nhh Oct 14 '16 at 08:09
  • for example, accessing a vector generated with malloc it's slower than accessing a vector generated in the stack, because of how it's allocated. – Francesco Di Lauro Oct 14 '16 at 08:12
  • @FrancescoDiLauro yes, that's true, `malloc` is relatively slow, but allocating on the stack limits you to the stack size which is usually rather small (typically 8 Mb or so) and the allocated object goes away as soon as you leave the function. – Jabberwocky Oct 14 '16 at 08:40
  • 2
    ...but once the memory has been allocated (on the stack or via malloc), accessing that memory will take the same time. – Jabberwocky Oct 14 '16 at 08:43
  • so the issue may be the time the program takes to allocate that memory, not the time to access that memory. So if I allocate a vecor as a global variable, it will take less time than allocating it using malloc. – Francesco Di Lauro Oct 14 '16 at 08:54
  • @FrancescoDiLauro first part of your statement: yes. Second part: if your vector is a global variable or if you allocated it _once_ with malloc at the start of the program won't make any difference. But if you can declare it as a global variable, then you know the size of the vector at compile time and then using `malloc` is pointless anyway. Maybe you should ask another question about your _actual_ proble, See [XY Problem](http://xyproblem.info/). – Jabberwocky Oct 14 '16 at 09:03

2 Answers2

5

See also this article before reading on (I am not talking about accessing stack versus heap):

Is accessing data in the heap faster than from the stack?

The architectures and memory management policies vary so vast that it is a hard article to discuss on. I will take Intel x86 as example.

Accessing data is just through a single instruction, no matter where we are accessing.

<INST> <SEG> : <ADDR>

The INST stands for instruction we are executing. The SEG stands for which segment we are accessing. And VADDR stands for the virtual address.

Under real mode, the SEG will be an base address to segment, and ADDR will be the address internal to segment. The efficiency accessing data under real mode seems to be the same amongst every segments. (No matter stack, heap, or global)

Under protected mode, the SEG will be a selector, and ADDR will be the virtual address. And the most tricky thing is that the MMU (Memory Management Unit) comes to work and blames who access data 'not expected'.

When the data you are accessing is not inside memory, the MMU generates a interrupt of page fault and requests OS to switch pages. And the MMU blames you by spending more time swapping pages with hard disk.

So it is just in vain merely talking about whether it is faster accessing global data or local without considering how data is accessed.

From my perspective, you are more likely to access stack 'local data' than global data, so the page fault probability may be higher when accessing global one.

Community
  • 1
  • 1
Haoran.Luo
  • 113
  • 1
  • 6
5

Stack and head are only implementation details, meaning that they could depend on the compiling environment. The C standard only defines the linkage and storage duration of identifiers. But you are right, stack, heap and data segment are the common implementation.

But you are wrong when you say accessing a variable stored in the heap is slower than accessing a local variable. Allocating and deallocating dynamic memory is indeed more complex and takes more time than using automatic variables, but during their lifetime, accessing (be it for reading or writing) costs exactly the same - at least on common infrastructure. What will make the difference is:

  • is the data in processor cache or in level 2 cache (speeds up access)
  • is the data in a currently swapped off page that needs to be reloaded from disk (slows down access)

But both can happen the same for dynamic, automatic or static data...

Serge Ballesta
  • 143,923
  • 11
  • 122
  • 252
  • Yes I got it now, thanks. But does this mean that allocating global memory takes exactly the same time than allocating memory in the stack? – Francesco Di Lauro Oct 14 '16 at 09:03
  • 1
    @FrancescoDiLauro: *allocating global memory* does not make much sense. Even standard say (6.2.4 Storage durations of objects) that global objects have *static storage duration* and that *[their] lifetime is the entire execution of the program*. So they are created at start up time and never deallocated. – Serge Ballesta Oct 14 '16 at 09:08