Feat: added memory section on performance

Author: L0STE

src/app/content/courses/pinocchio-for-dummies/performance/en.mdx

@@ -172,4 +172,72 @@ flags ^= FLAG_ACTIVE;               // flags = 0000_1001 (now has VERIFIED)
 flags ^= FLAG_LOCKED;               // flags = 0000_0001 (LOCKED now cleared)
 
 // Toggle multiple flags at once
-flags ^= FLAG_PREMIUM | FLAG_LOCKED;        // flags = 0000_1011
+flags ^= FLAG_PREMIUM | FLAG_LOCKED;        // flags = 0000_1011
+```
+
+<ArticleSection name="Memory on Solana" id="memory-on-solana" level="h2" />
+
+The Solana Virtual Machine (SVM) uses a three-tier memory architecture that strictly separates stack memory (local variables), heap memory (dynamic structures), and account space (persistent storage). 
+
+Understanding this architecture is crucial for writing high-performance Solana programs.
+
+Programs operate within fixed virtual address spaces with predictable memory mapping:
+- **Program Code**: `0x100000000` - Where your compiled program bytecode lives
+- **Stack Data**: `0x200000000` - Local variables and function call frames  
+- **Heap Data**: `0x300000000` - Dynamic allocations (expensive!)
+
+This deterministic layout enables powerful optimizations but also creates strict performance constraints.
+
+> Solana imposes strict memory limitations: 4KB stack frames per function call and 32KB total heap space per program execution.
+
+### The Zero-Allocation Advantage
+
+Pinocchio's main performance breakthrough comes from using references instead of heap allocations for everything. 
+
+This approach leverages a key insight: **the SVM already loads all your program inputs into memory**, so copying that data into new heap allocations is pure waste.
+
+Heap allocation isn't inherently bad, but on Solana it's expensive and complex because every allocation consumes precious compute units: each allocation fragments the limited heap space and cleanup operations consume additional compute units.  
+
+### Zero-Allocation Techniques
+
+1. Reference-Based Data Structures - Transform owned data into borrowed references:
+    ```rust
+    // HEAP ALLOCATION:
+    struct AccountInfo {
+        key: Pubkey,        // Owned data - copied to heap
+        data: Vec<u8>,      // Vector - definitely heap allocated
+    }
+
+    // ZERO ALLOCATION:
+    struct AccountInfo<'a> {
+        key: &'a Pubkey,    // Reference - no allocation
+        data: &'a [u8],     // Slice reference - no allocation
+    }
+    ```
+
+2. Zero-Copy Data Access - Access data in-place without deserialization:
+    ```rust
+    // Instead of deserializing, access data in-place:
+    pub fn process_transfer(accounts: &[u8], instruction_data: &[u8]) {
+        // Parse accounts directly from byte slice - NO HEAP ALLOCATION
+        let source_account = &accounts[0..36];  // Just slice references
+        let dest_account = &accounts[36..72];
+        
+        // Access fields through pointer arithmetic - NO ALLOCATION
+        let amount = u64::from_le_bytes(instruction_data[0..8].try_into().unwrap());
+    }
+    ```
+
+3. No-Std Constraints - Prevent accidental heap usage at compile time:
+    ```rust
+    // Enforces no-std to prevents accidental heap usage:
+    #![no_std]
+    ```
+
+### Pinocchio Memory Allocator
+
+If you want to make sure that you don't allocate any heap, Pinocchio provide a specialized macro to make sure that this happen: `no_allocator!()`
+
+> If not set, Pinocchio will use the `default_allocator!()` for programs requiring traditional heap operations.
+
+Other than this, you can always write a better heap allocator that knows how to clean up after itself. If you're interested in this approach, [here's an example](https://github.com/solana-labs/solana-program-library/blob/master/examples/rust/custom-heap/src/entrypoint.rs).