DEV Community: Mahdi Chaari

[Boost]

Mahdi Chaari — Mon, 16 Jun 2025 22:48:40 +0000

Mahdi Chaari

Jun 16 '25

C++, Unsafe Doesn’t Always Mean Dangerous : How I increased performance with raw pointers

#cpp #opengl #ffmpeg

Comments 2

3 min read

C++, Unsafe Doesn’t Always Mean Dangerous : How I increased performance with raw pointers

Mahdi Chaari — Mon, 16 Jun 2025 22:40:18 +0000

TL;DR:

When building a real-time video rendering and encoding pipeline in C++, I hit a surprising bottleneck: memory allocation. Despite using high-performance libraries like OpenGL and FFmpeg, the cost of safely copying ~5MB per frame killed my frame budget. The fix? Using raw pointers with a manually managed double buffer. It’s not idiomatic C++, but in this case, “unsafe” code—done carefully—was the only way to hit performance targets.

As a person who worked in managed runtimes like NodeJs and the Golang runtime, thinking about memory management always felt like premature optimisations because the runtime, or the underlying libraries generally handled it really well. However, in C++ it is the name of the game. The language offers multiple ways to manage memory and resource lifecycles like RAII, smart pointers and manual work using raw pointers. And in general it is never a good idea to work with raw pointers due to their complexity and risk. Leaks, dangling pointers, double frees… the list is long. But sometimes, performance demands pull you back into the wild.

I'll share a story, about how raw pointers saved my project from business unviability.

In a project I am working on, I have to Render 800 frames per second of 48GB of gpu assets then encoding them into real time video streams, all in real time, on a single powerful machine. If I can't achieve these numbers, the project dies.

The rendering side uses OpenGL; the encoding side uses libav (FFmpeg). Both are highly optimised but in completely different ecosystems.

At first glance, the heavy GPU work seemed like the obvious bottleneck:

Rendering 4M+ triangles per frame
Reading GPU memory back to the CPU
Passing the frame to the encoder

But after measuring… surprise: The bottleneck wasn’t GPU work.
It was memory allocation.

The Hidden Bottleneck: Memory Allocation

Back to the drawing board?

When planning the project, I did some benchmarks:

real-time encoding can be done quickly on the separate Nvenc ship ( or apple video toolbox on Apple Silicon)
Optimised rendering allows for huge gains even with large polygon count, and testing showed it could clearly meet our frame budget
Encoding and rendering are done on different dies in the GPU so they can be parallelised and shouldn't affect each other
we have a double buffer per stream, and since we're rendering in a round robin fashion, and since encoding is much faster than rendering, it is not possible that rendering is being blocked by the locking mechanism in place.

Looking at the estimates, putting everything together should work. But there was a problem hiding in plain sight.

Both OpenGL and libav manage their own memory layouts and object lifetimes. When bridging them, the easy (and “safe”) path is to copy frame data into a newly allocated buffer for each AVFrame.

That means allocating and copying ~5MB per frame, at hundreds or thousands of frames per second.
Across multiple threads.
While trying to maintain real-time performance.

That quickly became a page-fault storm. My rendering time per frame went from 1.3ms per frame to more than double that.

The Fix: Controlled Unsafe Code

So I broke the rules.

Instead of copying memory or using RAII, I created a manually-managed double buffer. Both OpenGL and libav operate on shared raw memory. I carefully coordinate access, and validate every pointer and layout match using source inspection and testing.

This is what optimized code sometimes looks like in C++:

struct DoubleBuffer {
    char* front;
    char* back;
    int size;
    void swap();
    char* frontBuffer();
    char* backBuffer();
    ~DoubleBuffer() {
        delete[] front;
        delete[] back;
    }
};

The renderer writes into the front buffer.

The encoder reads from the back buffer.

We swap them on each frame.

And we use the less-safe versions of AVFrame and Image that just wrap existing buffers.

No allocations. No copies. Just raw throughput.
Is it safe? Not in the traditional RAII sense.
But it is controlled, isolated, and fast.

In other higher level C++ code this feels like a crime, but reading the libraries source code, and ensuring safety through verification and understanding memory layout well is also called safety.

Sometimes encapsulation leads to performance traps, to the favor of clean and easy to use interfaces.

In C++, "unsafe" doesn't have to mean dangerous.
It can mean deliberate, validated, and surgical.

An Introduction for Developers to Information Security

Mahdi Chaari — Sat, 26 Aug 2023 12:50:37 +0000

Table of Content

Introduction - Remembering the man who saved 17 million lives
Information Security - Fifth dimension of warfare
Cybersecurity
Terminology
- IT Systems Failure
- Vulnerability, Threat, and Control
- The CIA Triad
Takeaway
About the Author

Introduction - Remembering the man who saved 17 million lives

In the depths of the North Atlantic on August 27, 1941, the stage was set for a pivotal moment in WWII.
The British captured a German U-boat, U-570, and seized its Enigma machine. The Enigma machine was a device used to encrypt and decrypt messages, and its capture was a major intelligence coup for the Allies.

The Enigma machine was very complex, and its encryption code changed daily. However, British mathematician Alan Turing and his team were able to break the Enigma code by exploiting a weakness in the system: every message started with the same phrase "Hail, [the Nazi's leader name]".

With the help of the Enigma machine, the Allies were able to read German communications, which gave them a major advantage in the war.
Today, there is a general agreement that the intelligence gathered by intercepting German communications, shortened the war by at least two years, saving an estimated 17 million lives.

These events exemplify the information security workflow in action.

For example, modifying encryption code serves as a control measure to mitigate potential exposure of enigma code, thereby reducing the threat of interception. Notably, during the war, Alan Turing exploited a vulnerability involving repeated strings to attack the German information system, gaining a strategic advantage.

Throughout this article, I aim to provide an introduction to information security and its associated terminology.

Information Security - Fifth dimension of warfare

Information security, often abbreviated as "InfoSec" refers to the practice of protecting information and data from unauthorized access, use, disclosure, disruption, modification, or destruction.
The formalization and standardization of Information Security became imminent during the events of WWII and made a huge impact on the Cold War, which was deemed by many as an Intelligence war.
Information operations were declared as the 5th dimension of Warfare, along side Land, Sea, Air and Space, on April 25, 1995 by United States Department of Defense.

Cybersecurity

People often confuse CyberSec and InfoSec, and given the emphasis we put on digitalization and how our world has become dependent on technology you can't really blame them. More often than not, information IS digital data. However, people involved in the software development process may benefit from the distinction.
Cybersecurity is concerned with securing different critical systems and sensitive information from unwanted access, meaning using the systems in ways that were not supposed to be allowed.
In more technical terms, cybersecurity protects against failures. For example, a failure to hide user-sensitive information or a failure to stop malicious actors from controlling sensitive resources, etc.

For a developer, understanding the technical terms and the basic foundational concepts used in cybersecurity, is very valuable, because it gives them an understanding of the abstractions they are using ( in the form of libraries, and API calls ... ).
In the next section, we're going to discuss some basic terminology from InfoSec and CyberSec which can be helpful when reading documentation and specifications.

Terminology

IT Systems Failure

An IT system failure is an event in which an IT system does not function as intended.

These failures can be best understood when viewed from the perspective of the intersection of these two dimensions:

Impact: Catastrophic vs Harmless.
Intent: Malicious vs Non-malicious.

By modeling failures in this way, we can see that they can fall into any of the four quadrants of the spectrum. The specific controls and strategies used to manage IT system failures depend on the type of failure.

Non-malicious failures are either physical failures such as hardware failures, natural disasters ... or either caused by human error. When designing systems, it is important to consider non-malicious failures and to evaluate their impact on the overall functioning of the system.

Malicious failures, on the other hand, are caused by intentional actions, such as cyberattacks. It is important to always assume that your system is under attack, no matter its scale.

To demonstrate how failures can vary on the impact spectrum, imagine a hacker targeting a company's Information System. If the hacker gains access to an internal administrative endpoint, it's a malicious failure to secure internal resources. Depending on the outcome:

It can be Harmless: The internal APIs are protected by a firewall from public access. The security team can detect this unwanted access and patch the non-critical issue and no harm is done to the system and data.
or Catastrophic: The internal APIs are not protected against external access, the hacker successfully gains access to internal information.

Vulnerability, Threat, and Control

Threats are blocked or prevented from being actualized by controlling vulnerabilities

Vulnerability: is a flaw in a system resulting from bad design or false assumptions. They weaken the overall security of the system.
Threat: is a potential event or action that may result in a system failure. Threats are facilitated by vulnerabilities to do any combination of the following harmful acts:
- fabrication (e.g.: creation of fake accounts)
- Modification (e.g.: adding money to a bank account)
- interception (e.g.: reading sensitive information)
- interruption (e.g.: overloading critical systems)
Control: also called countermeasure, is a measure or action taken to reduce the likelihood or impact of a threat. Controls can be technical, such as firewalls and intrusion detection systems, or non-technical, such as security awareness training.

This model helps us identify the weaknesses of a system, evaluate their impact, and make calculated decisions on how to solve them.
To illustrate this concept, imagine encountering a vulnerability within a critical dependency of our system. In assessing the potential threat presented by this vulnerability, the security team undertakes a thorough evaluation. Let's consider the example of the ReDoS vulnerability. ReDoS is a flaw often found in specific regex engines, triggering an infinite loop when certain characters are encountered. This loop, if triggered, can lead to system crashes and potential disruptions. In instances where the conditions for the vulnerability to be exploited are rare or improbable, the security team may determine that the associated threat is of negligible concern. Consequently, the necessity of implementing additional controls might be deemed unnecessary.

The CIA Triad

While the previous model gave a vulnerability assessment strategy, this model defines a set of system requirements, that, when met, the information system is deemed secure, according to the ISO Standard.

confidentiality: property that information is not made available or disclosed to unauthorized individuals, entities, or processes
integrity: property of accuracy and completeness
availability: property of being accessible and usable on demand by an authorized entity
information security: preservation of confidentiality, integrity and availability of information

- ISO/IEC 27000:2018

Information systems are composed of three main portions: hardware ( physical machines and devices ), software ( applications and services ), and communication ( networks and protocols ). Each component has its own industry standard for ensuring information security.

For instance, networks and telecom engineers ensure the secure transmission of information between endpoints through means of encryption, etc. This eliminates the interception threat ensuring confidentiality.
CPU designers, on the other hand, have integrated hardware level execution modes: kernel mode, and user mode to help protect the system from the threat of malicious code gaining access to critical system resources. This helps achieve all three CIA properties.
Software security experts, for example, have developed digital signatures, which can be understood as an encrypted stamp of authentication, that the receiving end can use to verify the integrity of a message.

Takeaway

Information security is a complex and ever-changing field. By understanding the different ways that systems can fail, how vulnerabilities can be exploited, and what properties make a system secure, we can build a mental model of information security.
Each system component can be viewed as a layer of security, and each person involved in the information system lifecycle has a specific role to play in ensuring the security of the system.
This mental model can help us make informed security decisions, and build secure systems that are resilient to attack.

About the Author:

Greetings! I'm Mahdi Chaari, a software engineering student with a keen interest in both software and hardware. I love diving into complex projects and figuring out how they work, with a particular focus on enhancing the developer experience.
I have an experience in full-stack web development. Currently, I'm hacking on security and DevOps.