Buffer Memory Management: Allocation, Pools, and Performance

Creating thousands or millions of small Buffers can be expensive if each one requires a separate memory allocation from the operating system. Node.js solves this problem with an intelligent buffer pool system that dramatically improves performance for common use cases.

Understanding how Node.js manages Buffer memory will help you write faster, more efficient code and avoid common performance pitfalls. This article explains the internal mechanisms that make Buffers fast and shows you how to optimize your Buffer usage.

What You Need to Know First

Required reading:

• Buffer Basics: Working with Binary Data in Node.js - You must understand what Buffers are and how to create them before learning about memory management

Helpful background:

• Basic understanding of memory concepts (stack, heap)
• Familiarity with performance profiling concepts

If you're not comfortable with Buffer creation methods (alloc, allocUnsafe, from), please read the previous article first.

What We'll Cover in This Article

By the end of this guide, you'll understand:

• How Node.js's buffer pool system works internally
• When buffers use the pool vs direct heap allocation
• How to control pool size and behavior
• Performance implications of different allocation strategies
• How to choose the right allocation method for your use case
• Memory efficiency techniques for working with Buffers

What We'll Explain Along the Way

These concepts will be explained as we encounter them:

• Memory allocation overhead (why it's expensive)
• The difference between pooled and unpooled memory
• Buffer pool internals (poolSize, poolOffset)
• Heap vs pool allocation strategies
• Performance measurement and benchmarking

The Problem: Memory Allocation is Expensive

Before we dive into buffer pools, let's understand why they're necessary.

Why System Memory Allocation is Slow

Every time you ask the operating system for memory, there's significant overhead:

// Each allocation requires system calls
const buf1 = Buffer.allocUnsafe(10); // System call #1
const buf2 = Buffer.allocUnsafe(20); // System call #2
const buf3 = Buffer.allocUnsafe(30); // System call #3
// Each one involves:
// 1. Switch from user space to kernel space
// 2. Find free memory in heap
// 3. Mark memory as allocated
// 4. Update memory management structures
// 5. Return control to Node.js
// This overhead adds up quickly!

Demonstration: Allocation Without Pool (Conceptual)

// Hypothetical: If every Buffer allocated from heap directly
console.time("Direct heap allocation");
for (let i = 0; i < 100000; i++) {
  // Imagine each requires a system call
  const buf = Buffer.allocUnsafeSlow(64); // Always heap allocation
}
console.timeEnd("Direct heap allocation");
// Result: ~500-800ms (slow!)

// Why so slow?
// 100,000 system calls
// Each with context switch overhead
// Memory fragmentation increases over time

The Solution: Buffer Pool

Node.js maintains a pre-allocated pool of memory and carves out small buffers from it:

// With buffer pool (what Node.js actually does)
console.time("Pooled allocation");
for (let i = 0; i < 100000; i++) {
  const buf = Buffer.allocUnsafe(64); // Uses pool
}
console.timeEnd("Pooled allocation");
// Result: ~10-20ms (much faster!)

// Why so fast?
// Only a few system calls to create pools
// Most allocations just slice from existing pool
// No context switches for each buffer

Visual Representation:

WITHOUT POOL:
Each buffer → Separate system call → Individual heap allocation

[Buffer 1] → System Call → Heap Block 1
[Buffer 2] → System Call → Heap Block 2
[Buffer 3] → System Call → Heap Block 3
...100,000 system calls...

WITH POOL:
One system call creates a large pool → Slice buffers from pool

System Call → [        8192-byte Pool          ]
                       ↓        ↓        ↓
               [Buf1][Buf2][Buf3][Buf4]...

Only a few system calls for pools!

How Buffer Pools Work

The Default Buffer Pool

When Node.js starts and you create your first small Buffer with allocUnsafe(), Node.js creates an 8192-byte (8 KB) pool:

// First small buffer creation
const buf1 = Buffer.allocUnsafe(100);

// What happens internally:
// 1. Node.js checks: "Do I have a pool?"
// 2. No pool exists yet
// 3. Create new pool: allocate 8192 bytes from heap
// 4. Slice first 100 bytes for buf1
// 5. Remember: 100 bytes used, 8092 bytes remaining

console.log(buf1.length); // 100 (buffer's size)
console.log(buf1.buffer.byteLength); // 8192 (pool's size)

Visual Representation of First Allocation:

BEFORE:
Memory: (empty)

AFTER FIRST allocUnsafe(100):
┌────────────────────────────────────────────────────┐
│              8192-byte Buffer Pool                 │
├──────────┬─────────────────────────────────────────┤
│  buf1    │          Available Space                │
│ 100 bytes│            8092 bytes                   │
└──────────┴─────────────────────────────────────────┘
   ↑
Used: 0 → 100
poolOffset: 100

Subsequent Allocations from the Same Pool

// Second buffer uses the same pool
const buf2 = Buffer.allocUnsafe(200);

// What happens:
// 1. Check existing pool: 8092 bytes available
// 2. 200 bytes needed - fits!
// 3. Slice bytes 100-300 from pool
// 4. Update: 300 bytes used, 7892 bytes remaining

console.log(buf2.buffer === buf1.buffer); // true (same pool!)

// Third buffer
const buf3 = Buffer.allocUnsafe(150);

// Pool now has:
// - Bytes 0-100: buf1
// - Bytes 100-300: buf2
// - Bytes 300-450: buf3
// - Bytes 450-8192: available

Visual Representation:

After buf1, buf2, buf3:
┌─────────────────────────────────────────────────────────┐
│              8192-byte Buffer Pool                      │
├────────┬─────────┬────────┬──────────────────────────┤
│  buf1  │  buf2   │  buf3  │    Available Space       │
│  100   │  200    │  150   │        7742 bytes        │
└────────┴─────────┴────────┴──────────────────────────┘
         ↑                   ↑
    poolOffset: 0 → 100 → 300 → 450

When the Pool Fills Up

// Allocate until pool is exhausted
const buf1 = Buffer.allocUnsafe(8000); // Uses 8000 bytes

// Only 192 bytes left in pool
const buf2 = Buffer.allocUnsafe(500); // Needs 500 bytes - doesn't fit!

// What happens:
// 1. Current pool only has 192 bytes
// 2. Need 500 bytes - won't fit
// 3. Create NEW pool: allocate another 8192 bytes
// 4. Slice first 500 bytes from new pool
// 5. Old pool's 192 bytes are wasted (abandoned)

console.log(buf1.buffer === buf2.buffer); // false (different pools!)
console.log(buf1.buffer.byteLength); // 8192 (old pool)
console.log(buf2.buffer.byteLength); // 8192 (new pool)

Visual Representation:

POOL 1 (mostly full):
┌──────────────────────────────────────────┬────┐
│         buf1 (8000 bytes)                │ 192│ ← Not enough for buf2
└──────────────────────────────────────────┴────┘

POOL 2 (new pool created):
┌────────────┬─────────────────────────────────────┐
│    buf2    │        Available Space              │
│  500 bytes │           7692 bytes                │
└────────────┴─────────────────────────────────────┘

Result: 192 bytes from Pool 1 are wasted

The 4096-Byte Threshold

Not all Buffers use the pool. Node.js has a size threshold:

// Small buffer: USES pool
const small = Buffer.allocUnsafe(100);
console.log(small.buffer.byteLength); // 8192 (from pool)

// Medium buffer: USES pool
const medium = Buffer.allocUnsafe(4095);
console.log(medium.buffer.byteLength); // 8192 (from pool)

// Large buffer: BYPASSES pool (heap allocation)
const large = Buffer.allocUnsafe(4096);
console.log(large.buffer.byteLength); // 4096 (exact size, not pooled)

// Why the threshold?
// The rule: Buffer.poolSize >> 1
// Default poolSize: 8192
// Threshold: 8192 >> 1 = 4096
// If buffer size >= 4096, allocate from heap directly

The Bitwise Right Shift Explained:

// Buffer.poolSize >> 1 means "divide by 2"
console.log(Buffer.poolSize); // 8192
console.log(Buffer.poolSize >> 1); // 4096

// Why use >> 1 instead of / 2?
// - Bitwise operations are faster than division
// - >> 1 shifts bits right by 1 position
// - Equivalent to dividing by 2 (integer division)

// Binary representation:
// 8192 = 10000000000000 (binary)
// >>  1 = 01000000000000 (shift right)
//      =  4096 (decimal)

When Buffers Use Pool vs Heap:

// Size < 4096: Pool allocation
const pooled1 = Buffer.allocUnsafe(1); // Pool ✓
const pooled2 = Buffer.allocUnsafe(1000); // Pool ✓
const pooled3 = Buffer.allocUnsafe(4095); // Pool ✓

// Size >= 4096: Direct heap allocation
const heap1 = Buffer.allocUnsafe(4096); // Heap ✓
const heap2 = Buffer.allocUnsafe(5000); // Heap ✓
const heap3 = Buffer.allocUnsafe(1048576); // Heap ✓ (1 MB)

// Verify:
console.log(pooled1.buffer.byteLength); // 8192 (pool)
console.log(pooled2.buffer.byteLength); // 8192 (pool)
console.log(pooled3.buffer.byteLength); // 8192 (pool)

console.log(heap1.buffer.byteLength); // 4096 (exact)
console.log(heap2.buffer.byteLength); // 5000 (exact)
console.log(heap3.buffer.byteLength); // 1048576 (exact)

Controlling Buffer Pool Behavior

Changing the Pool Size

You can modify the default pool size by changing Buffer.poolSize:

// Check default pool size
console.log(Buffer.poolSize); // 8192 (default)

// Change pool size to 16 KB
Buffer.poolSize = 16 * 1024;
console.log(Buffer.poolSize); // 16384

// Now the threshold is also larger
console.log(Buffer.poolSize >> 1); // 8192 (new threshold)

// Buffers smaller than 8192 will use pool
const buf1 = Buffer.allocUnsafe(7000);
console.log(buf1.buffer.byteLength); // 16384 (new pool size)

// Buffers >= 8192 will bypass pool
const buf2 = Buffer.allocUnsafe(8192);
console.log(buf2.buffer.byteLength); // 8192 (exact, not pooled)

Important Limitation:

// FIRST pool is always default size (8192)
const buf1 = Buffer.allocUnsafe(100);
console.log(buf1.buffer.byteLength); // 8192 (default size)

// Now change pool size
Buffer.poolSize = 16 * 1024;

// NEXT pool will use new size
const buf2 = Buffer.allocUnsafe(8500); // Needs new pool (doesn't fit in old one)
console.log(buf2.buffer.byteLength); // 16384 (new size)

// Why?
// The first pool is created when Buffer module loads
// Changing poolSize only affects FUTURE pools

When to Change Pool Size

Increase Pool Size (16 KB - 64 KB):

// Scenario: Many medium-sized buffers (2-8 KB)
Buffer.poolSize = 32 * 1024; // 32 KB

// Example: Processing many small files
async function processFiles(filePaths: string[]) {
  for (const path of filePaths) {
    const content = Buffer.allocUnsafe(5000); // Uses pool
    // Read file into buffer
    // Process...
  }
}

// With larger pool:
// - Fewer pool allocations
// - Less wasted space
// - Better performance for this workload

Decrease Pool Size (2 KB - 4 KB):

// Scenario: Mostly tiny buffers (<500 bytes)
Buffer.poolSize = 4 * 1024; // 4 KB

// Example: Many small network packets
function handlePackets() {
  for (let i = 0; i < 1000; i++) {
    const packet = Buffer.allocUnsafe(128); // Small packet
    // Process packet...
  }
}

// With smaller pool:
// - Less memory wasted
// - More efficient for tiny buffers
// - Fewer unused bytes in each pool

Keep Default (8 KB):

// Most applications should keep default
// Buffer.poolSize = 8192 (don't change)

// Default is optimal for:
// - Mixed buffer sizes
// - General purpose applications
// - When you're not sure about workload
// - Most file I/O operations

Disabling the Pool Entirely

Use Buffer.allocUnsafeSlow() to bypass the pool:

// Always allocate from heap (no pooling)
const buf1 = Buffer.allocUnsafeSlow(100);
const buf2 = Buffer.allocUnsafeSlow(100);

// Each buffer has its own ArrayBuffer
console.log(buf1.buffer === buf2.buffer); // false
console.log(buf1.buffer.byteLength); // 100 (exact)
console.log(buf2.buffer.byteLength); // 100 (exact)

// When to use:
// 1. Long-lived buffers that would waste pool space
// 2. Very large buffers (>= poolSize)
// 3. Buffers that need precise memory control

Performance Implications

Buffer.alloc() vs Buffer.allocUnsafe() Performance

Let's measure the real performance difference:

// Benchmark: Buffer.alloc() (safe, initialized)
console.time("Buffer.alloc (1KB)");
for (let i = 0; i < 1000000; i++) {
  const buf = Buffer.alloc(1024);
}
console.timeEnd("Buffer.alloc (1KB)");
// Output: ~50-100ms
// Why: Must zero out 1024 bytes for each buffer

// Benchmark: Buffer.allocUnsafe() (fast, pooled)
console.time("Buffer.allocUnsafe (1KB)");
for (let i = 0; i < 1000000; i++) {
  const buf = Buffer.allocUnsafe(1024);
}
console.timeEnd("Buffer.allocUnsafe (1KB)");
// Output: ~10-20ms (5x faster!)
// Why: No initialization, uses pool

// Benchmark: Buffer.allocUnsafeSlow() (no pool)
console.time("Buffer.allocUnsafeSlow (1KB)");
for (let i = 0; i < 1000000; i++) {
  const buf = Buffer.allocUnsafeSlow(1024);
}
console.timeEnd("Buffer.allocUnsafeSlow (1KB)");
// Output: ~80-150ms (slowest)
// Why: Heap allocation for each buffer

Size Matters: Pool vs Heap Performance

// Small buffers: Pool is MUCH faster
console.time("Pool: 100 bytes");
for (let i = 0; i < 1000000; i++) {
  const buf = Buffer.allocUnsafe(100); // Uses pool
}
console.timeEnd("Pool: 100 bytes");
// Output: ~10ms

console.time("Heap: 100 bytes");
for (let i = 0; i < 1000000; i++) {
  const buf = Buffer.allocUnsafeSlow(100); // Heap allocation
}
console.timeEnd("Heap: 100 bytes");
// Output: ~150ms (15x slower!)

// Large buffers: Similar performance
console.time("Pool: 5000 bytes");
for (let i = 0; i < 100000; i++) {
  const buf = Buffer.allocUnsafe(5000); // Bypasses pool (>4096)
}
console.timeEnd("Pool: 5000 bytes");
// Output: ~25ms

console.time("Heap: 5000 bytes");
for (let i = 0; i < 100000; i++) {
  const buf = Buffer.allocUnsafeSlow(5000); // Heap allocation
}
console.timeEnd("Heap: 5000 bytes");
// Output: ~30ms (similar performance)

// Lesson: Pool advantage is for small buffers (<4096 bytes)

Memory Efficiency Considerations

Pool Waste:

// Scenario: Creating many small buffers sequentially
const buffers: Buffer[] = [];

for (let i = 0; i < 1000; i++) {
  buffers.push(Buffer.allocUnsafe(100)); // Each uses 100 bytes
}

// Total buffer space used: 1000 * 100 = 100,000 bytes
// Actual memory allocated:
// - First pool: 8192 bytes (81 buffers fit, 92 bytes wasted)
// - Second pool: 8192 bytes (81 buffers fit, 92 bytes wasted)
// - ... (about 13 pools total)
// - Last pool: 8192 bytes (only 28 buffers, 5392 bytes wasted)

// Total allocated: ~13 * 8192 = ~106,496 bytes
// Actually used: 100,000 bytes
// Wasted: ~6,496 bytes (~6% waste)

// This is acceptable overhead for the performance gain!

Pool Sharing Side Effects:

// All pooled buffers share the same underlying ArrayBuffer
const buf1 = Buffer.allocUnsafe(10);
const buf2 = Buffer.allocUnsafe(10);

// They might share the same pool
console.log(buf1.buffer === buf2.buffer); // Often true

// Implication: If you keep references to many small buffers,
// you're also keeping the entire pool in memory

const keptBuffers: Buffer[] = [];
for (let i = 0; i < 100; i++) {
  keptBuffers.push(Buffer.allocUnsafe(10));
}

// Even though you're only using 1000 bytes,
// you're keeping multiple 8KB pools in memory!
// Total memory: ~13 pools * 8192 = ~106 KB (not just 1 KB)

Optimal Allocation Strategies

Strategy 1: Right-size your buffers

// ❌ Bad: Allocating too large
function readSmallData() {
  const buf = Buffer.alloc(1024); // Allocate 1 KB
  // But only use 50 bytes
  buf.write("Small data");
  return buf.slice(0, 10); // Waste 1014 bytes
}

// ✅ Good: Allocate what you need
function readSmallData() {
  const data = "Small data";
  const buf = Buffer.from(data); // Exactly sized
  return buf;
}

Strategy 2: Reuse buffers when possible

// ❌ Bad: Creating new buffer each time
function processMany(items: string[]) {
  for (const item of items) {
    const buf = Buffer.alloc(1024); // New buffer every iteration
    buf.write(item);
    processBuffer(buf);
  }
}

// ✅ Good: Reuse the same buffer
function processMany(items: string[]) {
  const buf = Buffer.alloc(1024); // Allocate once
  for (const item of items) {
    buf.fill(0); // Clear previous data
    buf.write(item);
    processBuffer(buf);
  }
}

Strategy 3: Choose allocation method by use case

// Use case: Temporary buffer, will overwrite immediately
function encodeData(data: number[]) {
  const buf = Buffer.allocUnsafe(data.length); // Fast, safe here
  for (let i = 0; i < data.length; i++) {
    buf[i] = data[i]; // Overwriting all bytes
  }
  return buf;
}

// Use case: Buffer for user input (security sensitive)
function handleUserInput(input: string) {
  const buf = Buffer.alloc(input.length); // Safe, zero-filled
  buf.write(input);
  return buf;
}

// Use case: Large file buffer (bypass pool)
async function readLargeFile(path: string) {
  const size = await getFileSize(path);
  const buf = Buffer.allocUnsafeSlow(size); // Direct heap allocation
  // Read file into buffer...
  return buf;
}

Common Pitfalls and Solutions

Pitfall 1: Memory Leaks from Pool References

// ❌ Problem: Keeping references to small pooled buffers
const smallBuffers: Buffer[] = [];

function leakyFunction() {
  for (let i = 0; i < 10000; i++) {
    const buf = Buffer.allocUnsafe(10); // Pooled
    smallBuffers.push(buf); // Keep reference
  }
}

leakyFunction();

// Result: 10,000 tiny buffers (100 KB of data)
// But: Keeping ~1,220 pools alive (~10 MB of memory!)
// Memory usage is 100x what you'd expect

// ✅ Solution: Copy small buffers if keeping long-term
const smallBuffers2: Buffer[] = [];

function nonLeakyFunction() {
  for (let i = 0; i < 10000; i++) {
    const buf = Buffer.allocUnsafe(10);
    // Copy to new buffer (breaks pool reference)
    smallBuffers2.push(Buffer.from(buf));
  }
}

// Now: 10,000 buffers, ~100 KB memory (expected!)

Pitfall 2: Wrong Pool Size for Workload

// ❌ Problem: Default pool size for unusual workload
// Scenario: Processing many 6 KB buffers
function processLargeBuffers() {
  const buffers: Buffer[] = [];
  for (let i = 0; i < 1000; i++) {
    buffers.push(Buffer.allocUnsafe(6000)); // 6 KB
  }
  // Each buffer bypasses pool (>4096)
  // Result: 1000 heap allocations (slow!)
}

// ✅ Solution: Increase pool size for this workload
Buffer.poolSize = 16 * 1024; // 16 KB

function processLargeBuffersEfficiently() {
  const buffers: Buffer[] = [];
  for (let i = 0; i < 1000; i++) {
    buffers.push(Buffer.allocUnsafe(6000)); // Now uses pool!
  }
  // Result: ~375 pool allocations (much faster)
}

Pitfall 3: Using allocUnsafe() for Long-Lived Buffers

// ❌ Problem: Long-lived pooled buffer blocks pool space
let globalBuffer: Buffer;

function initializeGlobalBuffer() {
  // This buffer lives for the entire application lifetime
  globalBuffer = Buffer.allocUnsafe(500); // Uses 500 bytes of pool
  // But keeps entire 8192-byte pool alive!
}

initializeGlobalBuffer();

// Later, trying to use pool for short-lived buffers
function processTemporary() {
  // Can't use the same pool (already has global buffer)
  const temp = Buffer.allocUnsafe(1000); // Might create new pool
}

// ✅ Solution: Use allocUnsafeSlow() for long-lived buffers
function initializeGlobalBufferCorrectly() {
  // Allocate from heap, not pool
  globalBuffer = Buffer.allocUnsafeSlow(500);
  // Doesn't block pool for other allocations
}

Pitfall 4: Mixing Pool and Heap Allocations Unnecessarily

// ❌ Inconsistent: Some pooled, some not
function inconsistentAllocation(sizes: number[]) {
  return sizes.map((size) => {
    if (size < 1000) {
      return Buffer.allocUnsafe(size); // Pooled
    } else {
      return Buffer.allocUnsafeSlow(size); // Heap
    }
  });
}

// Why bad?
// - Hard to predict memory behavior
// - Inconsistent performance characteristics
// - No clear benefit from mixing

// ✅ Consistent: Let Node.js decide
function consistentAllocation(sizes: number[]) {
  return sizes.map((size) => Buffer.allocUnsafe(size));
  // Node.js automatically uses pool for small, heap for large
}

Inspecting Buffer Memory Usage

Checking Buffer Pool Information

// Create some pooled buffers
const buf1 = Buffer.allocUnsafe(100);
const buf2 = Buffer.allocUnsafe(200);

// Check if they share a pool
console.log(buf1.buffer === buf2.buffer); // true (same pool)

// Check pool size
console.log(buf1.buffer.byteLength); // 8192

// Check buffer size
console.log(buf1.length); // 100
console.log(buf2.length); // 200

// Calculate pool usage
const poolBytes = buf1.buffer.byteLength; // 8192
const usedBytes = buf1.length + buf2.length; // 300
const wastedBytes = poolBytes - usedBytes; // 7892
const efficiency = ((usedBytes / poolBytes) * 100).toFixed(2);

console.log(`Pool usage: ${usedBytes}/${poolBytes} bytes (${efficiency}%)`);
// Output: Pool usage: 300/8192 bytes (3.66%)

Memory Profiling

// Measure memory before and after buffer allocation
const before = process.memoryUsage();

const buffers: Buffer[] = [];
for (let i = 0; i < 10000; i++) {
  buffers.push(Buffer.allocUnsafe(100));
}

const after = process.memoryUsage();

// Calculate memory increase
const heapIncrease = after.heapUsed - before.heapUsed;
const expectedMemory = 10000 * 100; // 1 MB

console.log(`Expected memory: ${expectedMemory} bytes`);
console.log(`Actual heap increase: ${heapIncrease} bytes`);
console.log(
  `Overhead: ${((heapIncrease / expectedMemory - 1) * 100).toFixed(2)}%`
);

// Example output:
// Expected memory: 1000000 bytes
// Actual heap increase: 1065536 bytes
// Overhead: 6.55%

Summary: Key Takeaways

Buffer Pool Fundamentals:

• Node.js uses a buffer pool to avoid expensive system memory allocations
• Default pool size is 8192 bytes (8 KB)
• Buffers smaller than 4096 bytes use the pool (threshold is poolSize >> 1)
• Buffers >= 4096 bytes bypass the pool and allocate directly from heap
• Pool is shared among all small buffers created with allocUnsafe()

Allocation Method Performance:

• Buffer.allocUnsafe() - Fastest for small buffers (uses pool, no initialization)
• Buffer.alloc() - Slower but safe (initializes to zero)
• Buffer.allocUnsafeSlow() - Bypasses pool, allocates from heap directly
• Buffer.from() - Uses allocUnsafe() internally, then copies data

Memory Efficiency:

• Pool waste is typically 5-10% - acceptable overhead for performance gain
• Long-lived small buffers keep entire pools in memory - use allocUnsafeSlow() instead
• Reuse buffers when possible - reduces allocation overhead
• Right-size your buffers - don't allocate more than needed

When to Change Pool Size:

• Increase (16-64 KB) - Many medium-sized buffers (2-8 KB)
• Decrease (2-4 KB) - Mostly tiny buffers (< 500 bytes)
• Keep default (8 KB) - Most applications (mixed sizes, general purpose)

Best Practices:

• Let Node.js handle pool vs heap decisions automatically
• Use allocUnsafe() for short-lived buffers you'll immediately overwrite
• Use alloc() for security-sensitive or user-facing data
• Use allocUnsafeSlow() for large or long-lived buffers
• Monitor memory usage in production to identify pool-related issues

What's Next?

Now that you understand Buffer memory management, you're ready to learn about Buffer operations:

• Buffer Operations - Reading, writing, copying, and manipulating binary data
• Buffer Methods - toString(), slice(), fill(), copy(), and comparison operations
• Working with different data types - Integers, floats, and multi-byte values