Continuous learning
  • My continuous learning
  • Algorithms
    • Big O notation
    • Binary Search
    • Bloom filters
    • Heap vs Stack
    • HyperLogLog
    • MapReduce
  • Architecture
    • Distributed architectures
    • Event-Driven architectures
    • Kubernetes architectures
    • Micro-service architectures
    • Multi-cluster architectures
    • OpenStack architectures
    • SDN architectures
    • Storage architectures
    • Video streaming architectures
  • Book Reviews
    • 97 things every SRE should know
    • Antifragility: Things That Gain from Disorder
    • Atomic Habits
    • The Black Swan: The Impact of the Highly Improbable
    • The Culture Map
    • The First 90 Days
    • Fooled by Randomness
    • The Phoenix Project
    • The Unicorn Project
    • The Three-Body Problem
  • Engineering
    • Problem Solving
  • Mind Maps
  • Miscellaneous
    • Building a modern development environment
    • Complexity
    • Conway’s law
    • Feynman technique
    • Food as a reflection of a culture
    • Leadership
    • Leading a team
    • Memory Chunking
    • Rules for life
    • Software architecture
    • Moral of understanding what you are doing
    • UX
  • Projects
    • Blue-Green Deployments with Argo Rollouts
    • Canary Deployments with Argo Rollouts and Istio
  • Reading material sources
  • Tech Stacks
    • Chaos
    • Kubernetes
      • kubectl
      • Kubernetes deep dive
      • Managing Kubernetes Clusters
      • Multi Cluster deployments
      • Topology awareness
      • Cert manager with let's encrypt
      • Harbor
      • Inspektor Gadget
      • Komodor
      • Kubershark
      • kubevirt
      • Kyverno
      • Let's encrypt
      • Mailhog
      • MetalLB
      • OpenShift
      • Robusta
      • ingress
        • Nginx Ingress
    • Home Lab
    • SRE
    • FaaS
      • Knative
    • FaaS
      • OpenFaaS
    • automation
      • CD
      • Argo Events
      • Workflows
      • Dagger
      • Gitea
      • GitHub
      • GitLab
        • GitLab image mapping
        • Deploying GitLab in multiple clusters
      • Pipeline definitions
        • Test multiple python versions for a release
      • Pulumi
      • stack
        • Full platform stack
      • Terraform
    • cloud-providers
      • AWS
      • Fly.io
    • databases
      • Atlas
      • Postgres
        • Postgres for Sysadmins
      • Redis
      • Vault
    • development
      • GraphQL
      • Development experience for the next century
      • UX
        • devcontainer
      • Using code server as a service
      • Go
      • nim
      • Python
        • Making Python Fast
        • Poetry
        • Python Zero Copy
      • Rust
      • UX
        • Skaffold
      • UX
        • Telepresence
      • UX
        • tilt
          • Tilt
    • linux
      • LXC
    • management
      • Backstage
      • Crossplane
    • monitoring
      • Grafana
      • Loki
      • OpenTelemetry
      • Prometheus
      • Spawn a full monitoring stack
      • Tempo
      • Victoriametrics
    • network
      • Calico
      • external Nginx for kubernetes ingress
    • os
      • mac
        • Configure MacOS
    • scm
      • Git
        • hooks
          • Pre-commit hook
    • security
      • CodeQL
    • service-mesh
      • Cilium service mesh
      • Consul
      • istio
        • Istio from the ground up
        • Istio Monitoring
        • Ambient mesh
        • Istio Sidecar Mode
      • Jaeger
      • LinkerD
    • storage
      • Ceph
      • MinIO
    • testing
      • k6
Powered by GitBook
On this page
  1. Algorithms

Heap vs Stack

When should you use the heap, and when should you use the stack? If you need to allocate a large block of memory (e.g. a large array, or a big struct), and you need to keep that variable around a long time (like a global), then you should allocate it on the heap. If you are dealing with relatively small variables that only need to persist as long as the function using them is alive, then you should use the stack, it's easier and faster.

If you need variables like arrays and structs that can change size dynamically (e.g. arrays that can grow or shrink as needed) then you will likely need to allocate them on the heap, and use dynamic memory allocation functions like malloc(), calloc(), realloc() and free() to manage that memory "by hand". We will talk about dynamically allocated data structures after we talk about pointers.

PreviousBloom filtersNextHyperLogLog

Last updated 2 years ago