Forem: TusharIbtekar

Understanding Goroutines, Concurrency, and Scheduling in Go

TusharIbtekar — Wed, 06 Aug 2025 19:03:48 +0000

If we talk about go, one of the most powerful features that go gives us is probably Go’s concurrency. But what exactly happens under the hood when we spawn goroutines? Specially on modern multi-core processors? Let’s dive deep:

Concurrency vs Parallelism

Before diving into Go’s internal, let’s get this out of the way -

Concurrency is the ability to structure a program as independently executing tasks. These tasks may not actually run at the same time, but they are designed to make progress independently. Concurrency, along with context switching, gives us a flavor of parallelism, where it makes us think processes are running at the same time, but when in actual case, it’s just jumping between processes while saving their states in Process Control Block(PCB) or Thread Control Block (TCB). How our CPU does this, is a tale of another day.
Parallelism means actually executing multiple tasks simultaneously.

Go enables concurrency by default via goroutines. Whether this results in parallelism depends on our hardware and the Go runtime’s configuration via GOMAXPROCS

Goroutine

Let’s lift the lid. What exactly is a goroutine? Its a lightweight, user-managed thread of execution. But here’s the catch, this is not like OS threads. Key differences are below:

Extremely cheap to create (initial stack ~2KB)
Scheduled cooperatively by the Go runtime, not by the OS
Capable of scaling into the millions without overwhelming the system

When we write:

go doWork()

We’re instructing the Go scheduler to start a new goroutine that will run doWork concurrently.

Go’s Scheduler: G, M, P Model

Go uses M:N Scheduler. Many goroutines(G) are multiplexed onto a smaller number of OS threads(M), which are coordinated using logical processors(P)

Components:

G: Goroutine
M: Machine (an actual OS thread)
P: Processor (logical context needed to execute Go code)

Only an M with an associated P can execute go code.

High-Level Diagram

How They Work Together

Each P manages a local queue of runnable goroutines.
Each P is attached to at most one M (OS thread) at a time.
An M runs one goroutine (G) at a time.
If a goroutine blocks (e.g. on I/O), the M detaches, and the P is reassigned to another available M to continue execution.

What Happens When We Start Many Goroutines?

Suppose, we are spawning 100,000 goroutines:

for i := 0; i < 1000000; i++ {
    go doWork(i)
}

On a machine with 16 logical CPUs (Logical CPUs are what we know as CPU threads - like 8 core processor has 16 threads), Go:

Initializes 16 Ps (by default GOMAXPROCS = 16)
Creates some Ms (OS threads) to execute goroutines
Distributes goroutines to the Ps’ local run queues

Each P runs one goroutine at a time using an M. As goroutines block or finish, the P selects the next goroutine in its queue.

Concurrency Through Context Switching

Context Switching Explained

Since the number of goroutines is often much greater than the number of available Ps or CPU threads, Go uses context switching to simulate concurrent execution.

When a goroutine blocks (e.g., on I/O or a channel), it is paused.
The scheduler saves its state (program counter, stack pointer, etc.), also known as TCB
The P picks another runnable goroutine and resumes it.
All of this is done in user space, without needing a system call, making it fast.

Single Core Example

Even with just one CPU core:

Only one goroutine can run at a time.
Go scheduler switches between goroutines, giving the illusion of concurrency.
This is achieved by cooperative and preemptive scheduling, context switching rapidly between runnable goroutines.

Ratios and Limits

P:M (Processor to Thread)

1:1 at a time: A P is bound to one M (OS thread) at a time.
If an M blocks, the Go scheduler finds another idle M to attach the P to.

P:G (Processor to Goroutines)

1:many: Each P maintains a queue of many runnable Gs.
Only one runs at a time on the P, but others wait in the queue.

M:G (Thread to Goroutines)

1:1 at a time: Each M executes one goroutine at a time.
The M is not aware of the queue — the P hands it a goroutine to run.

Work Stealing and Global Queue

If a P’s local queue is empty, it can:

Steal work from the queue of another P.
Pull work from the global run queue (used as a fallback).

This ensures that all processors stay busy and that goroutines are distributed evenly across available resources.

Parallelism with Multi-Core CPUs

On a processor that has 8 cores and 16 logical cores:

Go sets GOMAXPROCS = 16 by default.
This means up to 16 goroutines can be running in true parallel at any moment — one per logical core.
The rest of the goroutines are scheduled cooperatively.

So Go programs benefit from both parallelism (when hardware allows) and concurrency (even when limited to one core).

Conclusion

Whether we are running Go on a Raspberry Pi or a 32-core server, the same model adapts gracefully, letting us write clean concurrent code without worrying about locks, thread pools, or race conditions (beyond correctness).

If you're curious to dig deeper, tools like runtime/trace, pprof, and go tool trace can help you visualize how goroutines behave during execution.

Building a High-Performance Real-Time Chart in React: Lessons Learned

TusharIbtekar — Tue, 05 Aug 2025 18:16:37 +0000

Real-time data visualization is tricky. While many tutorials show you how to create basic charts, they often skip over the challenges of handling continuous data streams efficiently. Here's how I built a production-ready solution that handles thousands of data points while maintaining smooth performance.

The Common Pitfalls

Most basic real-time chart implementations look something like this:

const BasicChart = () => {
  const [data, setData] = useState([]);

  useEffect(() => {
    // DON'T DO THIS
    websocket.on('newData', (value) => {
      setData(prev => [...prev, value]);
      chartRef.current?.update();
    });
  }, []);

  return <Line data={data} />;
};

This approach has several problems:

Every data point triggers a re-render
Memory usage grows indefinitely
Chart animations cause jank
CPU usage spikes with frequent updates

A Better Architecture

The actual implementation uses a combination of WebSocket updates and REST API calls for initial data loading. This is a generalized version.

1. Smart Data Management

First, let's define our constants and types:

// constants.ts
export const CHART_CONFIG = {
  UPDATE_DELAY: 100,        // Debounce delay in ms
  INITIAL_RANGE: 600000,    // Initial time window (10 minutes)
  POINT_LIMIT: 1000,        // Maximum points to fetch initially
  POINT_THRESHOLD: 3000,    // Threshold before data cleanup
  CHANGE_THRESHOLD: 1       // Minimum change to record new point
};

interface TimeseriesData {
  metric: string;
  values: number[];
  timestamps: number[];
}

2. Intelligent Data Processing

The processNewDataPoint function handles both new WebSocket data and existing metrics
Here's how we handle new data points:

const processNewDataPoint = (
  existingData: TimeseriesData,
  newValue: number
): void => {
  const lastValue = existingData.values[existingData.values.length - 1];

  // Only record significant changes
  const hasSignificantChange = Math.abs(newValue - lastValue) > CHART_CONFIG.CHANGE_THRESHOLD;

  if (hasSignificantChange) {
    existingData.values.push(newValue);
    existingData.timestamps.push(Date.now());
  } else {
    // Update the last timestamp without adding duplicate data
    existingData.timestamps[existingData.timestamps.length - 1] = Date.now();
  }
};

3. Optimized Chart Component

The chart updates are optimized using chartRef.current?.update('none') to skip animations.
Here's our main chart component with performance optimizations:

const RealTimeChart: FC<RealTimeChartProps> = ({ metrics, dataSource }) => {
  const chartRef = useRef<ChartJS>();
  const [activeMetrics, setActiveMetrics] = useState<string[]>([]);

  // Debounced chart update
  const updateChart = useCallback(
    debounce(() => {
      chartRef.current?.update('none');
    }, CHART_CONFIG.UPDATE_DELAY),
    []
  );

  // Cleanup the chart instance and debounced function when the component unmounts
    useEffect(() => {
        return () => {
            // Cleanup the chart instance
            if (chartRef.current) {
                chartRef.current.destroy();
            }
            // Cleanup the debounced function
            updateChart.cancel();
        };
    }, [updateChart]);

  useEffect(() => {
    if (!dataSource) return;

    const handleNewData = (newData: MetricUpdate) => {
      // Process each metric
      metrics.forEach(metric => {
        if (!activeMetrics.includes(metric.id)) return;

        processNewDataPoint(metric, newData[metric.id]);
      });

      // Check if we need to clean up old data
      const shouldCleanup = metrics.some(
        metric => metric.values.length > CHART_CONFIG.POINT_THRESHOLD
      );

      if (shouldCleanup) {
        cleanupHistoricalData();
      }

      updateChart();
    };

    dataSource.subscribe(handleNewData);
    return () => dataSource.unsubscribe(handleNewData);
  }, [metrics, activeMetrics, dataSource]);

  return (
    <ChartContainer>
      <Line
        ref={chartRef}
        data={getChartData(metrics, activeMetrics)}
        options={getChartOptions()}
      />
      <MetricSelector
        metrics={metrics}
        active={activeMetrics}
        onChange={setActiveMetrics}
      />
    </ChartContainer>
  );
};

4. Performance-Optimized

Chart Configuration

export const getChartOptions = (): ChartOptions<'line'> => ({
  responsive: true,
  maintainAspectRatio: false,

  // Optimize animations
  animation: false,

  scales: {
    x: {
      type: 'time',
      time: {
        unit: 'minute',
        displayFormats: {
          minute: 'HH:mm'
        }
      },
      // Optimize tick display
      ticks: {
        maxTicksLimit: 8,
        source: 'auto'
      }
    },
    y: {
      type: 'linear',
      // Optimize grid lines
      grid: {
        drawBorder: false,
        drawTicks: false
      }
    }
  },

  elements: {
    // Disable points for performance
    point: {
      radius: 0
    },
    line: {
      tension: 0.3,
      borderWidth: 2
    }
  },

  plugins: {
    // Optimize tooltips
    tooltip: {
      animation: false,
      mode: 'nearest',
      intersect: false
    }
  }
});

Key Optimizations Explained

1. Selective Data Recording

Instead of recording every data point, we only store values when there's a significant change:

Reduces memory usage
Maintains visual accuracy
Improves processing performance

2. Efficient Updates

The debounced update pattern prevents excessive renders:

Groups multiple data updates into a single render
Reduces CPU usage
Maintains smooth animations

3. Data Cleanup

Implementing a point threshold system prevents memory issues:

Monitors total data points
Triggers cleanup when threshold is reached
Maintains consistent performance over time

4. Chart.js Optimizations

Several Chart.js-specific optimizations improve performance:

Disabled point rendering for smoother lines
Removed unnecessary animations
Optimized tooltip interactions
Reduced tick density
Simplified grid lines

Results

This implementation has several advantages over simpler approaches:

Memory Efficient: Only stores necessary data points
CPU Friendly: Minimizes renders and calculations
Smooth Updates: No visual jank during updates
Scale-Ready: Handles thousands of points efficiently
User Friendly: Maintains responsive interactions

Future Optimizations

While the current implementation is well-optimized for typical use cases, there are several potential future enhancements:

Web Workers Integration
- Offload data processing to a separate thread
- Improve main thread performance for larger datasets
- Enable more complex data transformations without UI impact
Progressive Loading
- Implement virtual scrolling for historical data
- Load data chunks based on viewport
- Improve initial load performance

Conclusion

Building an efficient real-time chart requires careful consideration of data management, render optimization, and user experience. While the implementation is more complex than basic examples, the benefits in performance and reliability make it worthwhile for production applications.
The key is finding the right balance between:

Update frequency vs. performance
Data accuracy vs. memory usage
Visual quality vs. render speed

This solution provides a solid foundation that can be adapted for various real-time visualization needs while maintaining excellent performance characteristics.

Any suggestions for further improvements would be appreciated 😀

How a Compiler Works: A Simple Breakdown

TusharIbtekar — Mon, 09 Sep 2024 16:49:29 +0000

Ever wondered how your code gets converted into something a computer can actually run? That's where a compiler comes in! Think of it like a translator, turning your high-level code (which humans understand) into machine code (which computers understand).

In this blog, we'll walk through the stages of a compiler with a simple example. By the end, you'll have a clearer picture of what's going on under the hood when you hit "run."

Our Example Code

x = 10 + y * z;

This is a basic expression that assigns a value to x. But before x can hold the result, the compiler must break this down step-by-step.

The Steps of a Compiler

Lexical Analysis
The compiler reads your code and breaks it into tokens - basic units like keywords, variables, and operators. For example, in x = 10 + y * z;, the tokens are x, =, 10, +, y, *, z.
Parsing
The tokens are organized into an Abstract Syntax Tree (AST), showing the structure and order of operations. This tree represents how the operations in your code are related.
The compiler creates a symbol table to track variables and their details. It keeps track of which variables exist and their types.
Semantic Analysis
The compiler checks the AST for logical correctness. It ensures variables are declared and used properly, and that operations are valid, updating the symbol table as necessary.
Intermediate Representation (IR)
The AST is converted into an Intermediate Representation (IR). This is a simplified version of your code, breaking down complex operations into more manageable steps.
Optimizer
The Optimizer tries to optimize the intermediate generated code.
Code Generation
Finally, the compiler translates the IR into machine code or assembly code that the CPU can execute. This low-level code consists of direct instructions for the computer's hardware.

Wrapping Up

The process - from tokenizing your code to generating machine code - ensures your program is correctly interpreted and executed by the computer. Each step plays a crucial role in transforming your high-level instructions into something the machine can understand.