# inlining Inlining is a compiler optimization that integrates a function's code into its callers to eliminate function-call overhead and potentially improve execution speed. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Profile-guided optimization in Go DevFeed: [Profile-guided optimization in Go]() Original publisher: [Read original article]() Author: Daniel Lemire Published: 2026-08-09T23:17:36Z Content type: article Language: en Sources: [Daniel Lemire]() Topics: [Go Language](), [Optimization](), [Compiler](), [inlining](), [JSON]() Tags: [compiler](), [cpu](), [go](), [inlining](), [interface](), [json](), [measurement](), [optimization](), [profile](), [profiling](), [speed](), [standard-library](), [systems]() ### AI overview This article explains how profile-guided optimization in Go uses runtime measurements to guide compiler decisions such as inlining hot call sites and devirtualizing interface calls. It also describes a benchmark parsing three JSON documents with separately trained PGO builds and comparing their speed against a profile-free baseline. ### Source excerpt When a compiler optimizes your program, it has to guess. Which functions are worth inlining? Which side of a branch is the common one? Which method does this interface call actually reach? At compile time it cannot know, so it uses heuristics. Profile-guided optimization (PGO) replaces the guessing with measurement: you run your program, record ... Continue reading Profile-guided optimization in Go ## Optimizing Jetpack Compose Transform Computations by Merging Functions DevFeed: [Optimizing Jetpack Compose Transform Computations by Merging Functions]() Original publisher: [Read original article]() Author: Romain Guy Published: 2025-05-15T00:00:00Z Content type: tutorial Language: en Sources: [Posts on Romain Guy]() Topics: [Code](), [Compose](), [Jetpack Compose](), [Kotlin](), [inlining]() Tags: [android](), [code](), [compose](), [developer](), [function](), [graphics](), [implementation](), [inlining](), [jetpack-compose](), [kotlin](), [merge](), [performance]() ### AI overview This article explains how merging or manually inlining low-level functions can remove duplicated work in performance-sensitive code. Using Jetpack Compose matrix transformations as an example, it describes eliminating unnecessary temporary matrices and intermediate computations. ### Source excerpt There is a simple but often overlooked technique to optimize performance-sensitive code: merging (or manually inlining) functions. We often build series of low-level functions that execute various computations that we then combine to perform higher-level tasks. When taken in isolation, each of those functions does exactly what it should and might even be perfectly optimized. However, when a series of thosefunctions work together, unnecessary or duplicated work might appear. Let's look at a concrete example taken from the Jetpack Compose code base. To apply the various geometric transforms that may affect a layer, Compose needs to build a matrix that combines all the transformations exposed by its APIs: ## Eliminating Array Bounds Checks DevFeed: [Eliminating Array Bounds Checks]() Original publisher: [Read original article]() Author: Romain Guy Published: 2025-05-13T00:00:00Z Content type: tutorial Language: en Sources: [Posts on Romain Guy]() Topics: [Android](), [Kotlin](), [Memory Safety](), [Compiler](), [Exception](), [toolchain](), [inlining]() Tags: [android](), [assembly](), [code](), [compiler](), [developer](), [exception](), [graphics](), [inlining](), [kotlin](), [memory-safety](), [performance](), [toolchain]() ### AI overview This tutorial explains how Android Runtime array bounds checks protect memory safety but can add unnecessary instructions. It shows how a simple explicit check can help the compiler eliminate those checks in a fixed-size array, reducing the example from 136 to 60 arm64 instructions. ### Source excerpt The Android Runtime (ART) offers a nice memory safety feature when accessing the content of an array. The indices you use are automatically checked against the bounds of the array to prevent unsafe memory accesses. To achieve this, ART generates extra machine instructions to throw an ArrayIndexOutOfBoundsException when the index is invalid. Here is a simple Kotlin example: 1fun scaleZ(values: FloatArray, scale: Float) = values[2] * scale After translation to arm64 assembly, we obtain the following result: ## Micro-optimizations in Kotlin -- 2 DevFeed: [Micro-optimizations in Kotlin -- 2]() Original publisher: [Read original article]() Author: Romain Guy Published: 2024-01-16T00:00:00Z Content type: tutorial Language: en Sources: [Posts on Romain Guy]() Topics: [Kotlin](), [Code](), [inlining](), [Android](), [Assembly]() Tags: [android](), [assembly](), [code](), [developer](), [graphics](), [implementation](), [inlining](), [kotlin](), [performance]() ### AI overview This article examines micro-optimizations for Kotlin's Float.sign and Double.sign APIs. It explains their handling of negative and positive values, signed zero, and NaN, then compares the Kotlin implementation with Android's generated AArch64 assembly. The article shows how inlining and intrinsics eliminate function calls and translate the implementation into bit manipulation. ### Source excerpt In the previous post, we saw how we could micro-optimize Int.sign to save a few instructions. We are now going to turn to Float.sign (and by extension Double.sign). Float.sign returns the sign of single-precision float value as a single-precision float value. While similar to Int.sign, this API must handle a special cases: Not-a-Number (NaN). The exact behavior of the API is that it will return: -1.0f if the value is negative +/-0.0f if the value is zero (floats can encode both positive and negative zero) 1.0f if the value is positive NaN if the value is NaN An easy way to implement this API ourselves is to return the input when the input equals 0.0f or NaN, and to return the input's sign copied onto 1.0f otherwise. Translated to code, we can write: ## Kotlin's inline and suspend features DevFeed: [Kotlin's inline and suspend features]() Original publisher: [Read original article]() Author: Simon Vergauwen Published: 2022-01-18T00:00:00Z Content type: article Language: en Sources: [nomisRev]() Topics: [Kotlin](), [inlining](), [async](), [Compiler]() Tags: [async](), [callback](), [compiler](), [concurrency](), [continuation](), [dsl](), [function](), [hof](), [inlining](), [kotlin](), [suspend]() ### AI overview This article explains Kotlin's inline feature and suspend functions, focusing on how their combination supports efficient higher-order functions and imperative code for asynchronous workflows. It also describes compiler checks for suspending calls. ### Source excerpt Over the last several years I've seen many discussions on Kotlin's features. Nullability is always a very high ranked one. I like it, but it's definitely not my favorite feature. ## Performant A/B Testing with Cloudflare Workers DevFeed: [Performant A/B Testing with Cloudflare Workers]() Original publisher: [Read original article]() Published: 2021-12-20T14:01:14Z Content type: tutorial Language: en Sources: [Philip Walton]() Topics: [A/B Testing](), [Cloudflare Workers](), [Latency](), [inlining]() Tags: [a-b-testing](), [cloudflare-workers](), [edge-computing](), [inlining](), [performance]() ### AI overview This tutorial explains how to run performant A/B tests with Cloudflare Workers at the edge. It discusses the performance costs of client-side and origin-based server-side testing and introduces a cookie-based approach for assigning users to experiment groups. ### Source excerpt I think there's a perception in our industry that A/B testing is super complicated and you really need a tool or service to do it right. And while I'm sure some aspects of A/B are quite complex ## Smarter C/C++ inlining with \_\_attribute\_\_((flatten)) DevFeed: [Smarter C/C++ inlining with \_\_attribute\_\_((flatten))]() Original publisher: [Read original article]() Author: Andreas Kling Published: 2020-04-27T00:00:00Z Content type: tutorial Language: en Sources: [Andreas Kling]() Topics: [inlining](), [c/c++](), [Optimization](), [clang](), [gcc](), [build times]() Tags: [build-times](), [c-c-plus-plus](), [clang](), [compiler](), [cpp](), [function](), [gcc](), [inlining](), [optimization](), [performance](), [technical]() ### AI overview This post explains how to use the __attribute__((flatten)) function attribute in C/C++ to apply aggressive inlining selectively. GCC and Clang support the attribute, which inlines a function's callees while limiting the program-size, cache-locality, and build-time costs of broader inlining. ### Source excerpt This post describes a compile-time technique for getting the benefits of aggressive inlining in hot code while protecting cool code from its downsides. ## JavaScript Performance Pitfalls in V8 DevFeed: [JavaScript Performance Pitfalls in V8]() Original publisher: [Read original article]() Author: benedikt.meurer@googlemail.com (Benedikt Meurer) Published: 2019-03-05T16:32:03Z Content type: article Language: en Sources: [Pony Foo]() Topics: [JavaScript](), [V8](), [Compiler](), [Optimization](), [inlining](), [Programming]() Tags: [bytecode](), [compilation](), [compiler](), [function](), [inlining](), [internals](), [javascript](), [optimization](), [performance](), [v8]() ### AI overview This article explains two performance pitfalls in the V8 JavaScript engine. It discusses engine heuristics such as speculative optimization and inline caching, then describes V8's method-based JIT compilation, optimization limits, and inlining. ### Source excerpt In recent years, JavaScript engines have improved on all fronts. The performance of JavaScript has reached a level where it can easily compete with programming languages that have traditionally been considered more appropriate for high-performance computing. This is not only true for V8, the JavaScript engine inside of Chrome and Node.js, but for all major JavaScript engines, including ChakraCore, the engine inside of Edge, JavaScriptCore, the engine inside of Safari, and SpiderMonkey, the engine inside of Firefox. Not only did the peak performance improve, but engines also managed to deliver more consistent and predictable levels of performance. Given that JavaScript is a highly dynamic language, all of this performance is based on choosing the right heuristics in the engine. JavaScript engines use techniques like speculative optimization and inline caching to speed up execution of the likely path. But heuristics can also easily work against you, and it helps to be aware of them. So today I'm gonna share some background on two subtle performance pitfalls in the V8 JavaScript engine. Being aware of these potential pitfalls might help you to resolve issues if you get bitten by these more easily. Optimization limit The compilers built into V8 - both the TurboFan optimizing compiler and the Ignition bytecode generator - are so-called method JITs, meaning the unit of compilation is always a method, aka a function in JavaScript speak. The optimizing compiler is able to include the bodies of other methods when it finds hot call sites and sees potential for further optimizations via doing this, which is commonly referred to as inlining. Contrast this with other runtimes that use so-called tracing JITs - LuaJIT and PyPy are popular examples here - where the unit of optimization is an arbitrary sequence of consecutive bytecodes that have been executed repeatedly previously. In both method JITs as well as tracing JITs, there's always an upper limit on the size of the input th ## Implementing Critical CSS on your website DevFeed: [Implementing Critical CSS on your website]() Original publisher: [Read original article]() Author: andrew@nystudio107.com (Andrew Welch) Published: 2017-02-28T21:34:00Z Content type: tutorial Language: en Sources: [nystudio107 | Articles on modern web development.]() Topics: [modern web development](), [Web Development](), [Front end](), [inlining](), [render](), [Website]() Tags: [article](), [browser](), [critical](), [development](), [essential](), [frontend](), [how-to](), [implementing](), [inlining](), [insights](), [modern](), [modern-web-development](), [performant](), [render](), [shows](), [website]() ### AI overview This tutorial explains Critical CSS, a method for extracting the CSS needed for above-the-fold content and inlining it so the browser can render the page immediately. It presents the technique as part of building performant websites. ### Source excerpt Implementing Critical CSS is an essential part of modern website development, this article shows you how to do it ## Final fields DevFeed: [Final fields]() Original publisher: [Read original article]() Published: 2016-12-03T00:00:00Z Content type: tutorial Language: en Sources: [Paweł Chudzik]() Topics: [Hibernate](), [Java](), [inlining](), [Optimization]() Tags: [bytecode](), [hibernate](), [inlining](), [java](), [optimization](), [trace]() ### AI overview This tutorial explains how private final fields can be modified through reflection, including how Hibernate uses the technique to hydrate final entity fields. It also demonstrates how Java compile-time constants and inlining can cause modified primitive final fields to behave unexpectedly, while object fields such as Long can reflect the changed value. ### Source excerpt Private final field modification is possible and it doesn't require a lot of work. Since you should not use this mechanism in real life there are cases when it is useful. For example this how is Hibernate using this to hydrate final entity fields. But when using final fields with Hibernate you should be extra careful how you declare them. Read more ## Sorting improvements in PostgreSQL 9.2: the case for micro-optimisation DevFeed: [Sorting improvements in PostgreSQL 9.2: the case for micro-optimisation]() Original publisher: [Read original article]() Author: Peter Geoghegan (noreply@blogger.com) Published: 2012-08-02T02:04:00Z Content type: article Language: en Sources: [Peter Geoghegan's blog]() Topics: [PostgreSQL](), [Sorting](), [Compiler](), [Programming](), [inlining]() Tags: [c](), [compiler](), [cpu](), [inlining](), [performance](), [postgresql](), [sorting]() ### AI overview This article explains the development of PostgreSQL 9.2 sorting improvements. The approach specialized quicksort code, used compiler inlining and generated specializations, and reduced indirection in comparator calls. The article states that simple in-memory integer and floating-point sorting became about 23% faster. ### Source excerpt There has been much discussion of performance improvements in the upcoming 9.2 release of PostgreSQL. Recently, I noticed that Regina Obe and Leo Hsu's new book, "PostgreSQL: Up and running" prominently listed "Sorting improvements that improve in-memory sorting operations by as much as 20%" as a performance feature of that release. While they do get things about right there, I'm not sure that this improvement warrants such prominent placement, at least in sheer terms of its likely impact on the performance of production PostgreSQL systems - we packed a lot of great performance improvements into 9.2. The likely reason that it was picked up on in the book, and the real reason for this blogpost, is the story behind the development of the optimisation, which I for one find kind of interesting, and worth sharing. It's more interesting from the perspective of someone with a general interest in systems programming or PostgreSQL's design philosophy than a casual user, though. If you're a casual user, the short version is that simple queries that perform in-memory sorting of integers and floats will be about 23% faster. I wrote a rough prototype of the patch, that had a number of ideas, and proved the viability of the approach. Principal among those ideas was specialisation of the quicksort code: Formatting the code such that the compiler had compile-time knowledge of functions, with inlining used as an enabling optimisation, and a few variations produced. So rather than using complex indirection involving function pointers, a macro infrastructure was used to generate multiple specialisations, allowing the compiler to optimise the code more effectively as a result of being able to integrate everything. A secondary problem was that comparators (i.e. the comparison functions that all sorting within Postgres currently needs) were accessed in a round-about away. Roughly speaking, tuplesort (the part of the code that deals with sorting tuples, perhaps as part of a query's execut