# inlining Published articles for inlining. 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: ## Crafting Android bytecode analysis tooling using a secret ingredient (Part 1) DevFeed: [Crafting Android bytecode analysis tooling using a secret ingredient (Part 1)]() Original publisher: [Read original article]() Author: Konstantin Zolotov Published: 2024-02-09T11:50:19Z Content type: tutorial Language: en Sources: [Bumble Tech]() Topics: [Android](), [Tooling](), [APK](), [obfuscation](), [R8](), [Kotlin](), [Java](), [Compiler]() Tags: [andriod-app-development](), [android](), [apk](), [bytecode](), [compilation](), [compiler](), [dagger](), [inlining](), [java](), [kotlin](), [obfuscation](), [optimization](), [r8](), [tooling]() ### AI overview This tutorial introduces Android bytecode analysis through DEX inspection and a tool for examining how source-code changes affect compiled binaries. It explains the Android compilation pipeline from Java or Kotlin source through JVM class files and D8-generated DEX files, then describes R8 obfuscation and optimization, including source maps, tree-shaking, inlining, and outlining. ### Source excerpt During the development process, we often focus on the source code but rarely inspect the compiled bytecode. This means we're missing out on a valuable source of information and data for analysis. How? Let's delve into Dex file inspection and build a tool that demonstrates how source code changes impact the compiled binary. Have you ever set R8 rules to obfuscate your app? Have you used an APK analyzer or a diffuse tool to understand how the code is compiled? Are you confident that debug code hasn't leaked into production? There's another potential pitfall: libraries may provide obfuscation rules (e.g., Gson) that merge with the ones in your project. This means third-party dependencies can alter configurations for the entire app. We often assume everything is fine and that we'll notice if something isn't right. But will we? Does this make you feel uneasy? Does it concern you? Because it certainly concerns me. Here, we'll attempt to enhance the situation and enable you to see precisely how your code changes impact the compiled binary. To better comprehend this, let's start with the code compilation process: It all begins with the Java and/or Kotlin source code, which is then compiled into JVM .class files. Note that at this stage, Java and Kotlin compilers can execute annotation processing tools (APT/KAPT) to generate source code (e.g., Dagger), and Kotlin compiler can run plugins to modify the internal code representation. Then, the D8 compiler takes these compiled classes, third-party libraries (JARs, AARs), and converts them into .dex files. However, if obfuscation and/or minification are enabled (which is almost always the case for release builds), R8 comes into play after D8. R8 obfuscates and optimises the bytecode, and additionally, R8 produces a source map file -- a special file listing all the changes and replacements. Obfuscation replaces human-readable names of various entities (classes, functions, fields, etc.) with very short, yet still unique names, for e ## 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: ## Interfaces 101 : Heap Escape Ep. 2 DevFeed: [Interfaces 101 : Heap Escape Ep. 2]() Original publisher: [Read original article]() Published: 2023-02-08T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [interfaces](), [Go Language](), [Benchmark](), [Compiler](), [Code](), [Logging]() Tags: [benchmark](), [compiler](), [escape-heap](), [function](), [generic](), [go](), [golang](), [inlining](), [interfaces](), [log-variables](), [logging](), [performance]() ### AI overview This video examines the performance implications of using interfaces in Go, including how interface use can cause variables to escape to the heap. It demonstrates benchmarking code, examining compiler optimizations, identifying heap allocations, and preventing function inlining. ### Source excerpt Introduction In episode 1, Miki had two functions that performed the similar operation, but returned different types. To refactor this, Miki rewrote both functions as a generic function that allowed him to specify the type to be returned during invocation. In some cases, the compiler may not recognise a type, thus, Miki gives a few pointers on manually telling a generic function which type to use. After demonstrating how to return different types with a generic function, Miki limited the types his generic function would accept with an interface. ## Counting over Range Predicates DevFeed: [Counting over Range Predicates]() Original publisher: [Read original article]() Author: Richard Startin's Blog Published: 2022-03-27T00:00:00Z Content type: tutorial Language: en Sources: [Richard Startin's Blog]() Topics: [Java](), [Streams](), [Sorting](), [Benchmark](), [Code]() Tags: [benchmark](), [effective](), [filter](), [inlining](), [java](), [modularity](), [performance](), [roaring](), [sorting](), [streams]() ### AI overview This post examines counting objects that satisfy range and other filters when no database is available. It compares Java's Stream API with specialized Java code and finds that exploiting data already sorted by time can make filtering and counting more efficient. ### Source excerpt This post follows on from my last post about selecting objects satisfying a range predicate, and instead looks at how to count the objects. If you can select objects, you can count them too, but it's a simpler problem so resources can be saved with a specialised solution. ## 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 ## Mid-stack inlining in Go DevFeed: [Mid-stack inlining in Go]() Original publisher: [Read original article]() Author: Dave Cheney Published: 2020-05-02T05:09:15Z Content type: article Language: en Sources: [Dave Cheney]() Topics: [Go Language](), [Compiler]() Tags: [compilation](), [compiler](), [go](), [inlining](), [optimisation](), [performance](), [programming]() ### AI overview This article explains the limits of inlining in Go, comparing leaf and mid-stack inlining. It covers the trade-offs among execution speed, compile time, binary size, optimization opportunities, and the compiler's inlining budget. ### Source excerpt In the previous post I discussed how leaf inlining allows the Go compiler to reduce the overhead of function calls and extend optimisation opportunities across function boundaries. In this post I'll discuss the limits of inlining and leaf vs mid-stack inlining. The limits of inlining Inlining a function into its caller removes the call's overhead [...] ## 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. ## Inlining optimisations in Go DevFeed: [Inlining optimisations in Go]() Original publisher: [Read original article]() Author: Dave Cheney Published: 2020-04-25T06:38:17Z Content type: article Language: en Sources: [Dave Cheney]() Topics: [Go Language](), [Compiler](), [Code]() Tags: [compilation](), [compiler](), [compilers](), [function](), [go](), [goroutines](), [inlining](), [optimisation](), [performance](), [programming]() ### AI overview This article explains how the Go compiler implements function inlining and how the optimization affects Go code. It focuses on gc, the de facto Go compiler from golang.org, while noting that other Go compilers may differ in implementation and effectiveness. ### Source excerpt This is a post about how the Go compiler implements inlining and how this optimisation affects your Go code. n.b. This article focuses on gc, the de facto Go compiler from golang.org. The concepts discussed apply broadly to other Go compilers like gccgo and tinygo but may differ in implementation and efficacy. What is inlining? [...] ## Diving deep into Android Dex bytecode DevFeed: [Diving deep into Android Dex bytecode]() Original publisher: [Read original article]() Published: 2020-02-02T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [Android](), [Kotlin](), [R8](), [Compiler](), [Java](), [Mobile]() Tags: [android](), [bytecode](), [compiler](), [inlining](), [java](), [kotlin](), [memory](), [performance](), [r8]() ### AI overview This practical guide explains how Kotlin and Java code is transformed into Android DEX bytecode. It describes examining Java bytecode, the role of the Dalvik bytecode format and Android Runtime, and the compilation tools kotlinc, javac, d8, and R8, with attention to possible memory and performance effects. ### Source excerpt Source Introduction Modern Android development is based on Kotlin, which is interoperable with Java. Whenever we use some cool feature from Kotlin (say High-order functions) under the hood (when running on JVM) the feature is implemented in terms of Java bytecode. This might lead to some overheads in memory and performance if used without caution (for example excessive usage of lambdas with parameters without inlining might produce a lot of anonymous classes and put additional pressure on GC). ## R8 Optimization: Class Reflection and Forced Inlining DevFeed: [R8 Optimization: Class Reflection and Forced Inlining]() Original publisher: [Read original article]() Published: 2019-09-25T00:00:00Z Content type: article Language: en Sources: [Jake Wharton]() Topics: [R8](), [Optimization](), [Android](), [obfuscation]() Tags: [android](), [code](), [inlining](), [obfuscation](), [optimization](), [r8]() ### AI overview This article explains how R8 optimizes Java class reflection in Android applications. It contrasts static class literals with instance getClass() calls, then describes how whole-program analysis can replace reflective calls with known class references and string constants. It also examines a case where method inlining is blocked by method-size limits and introduces forced inlining through R8 configuration rules compatible with ProGuard. ### Source excerpt Note: This post is part of a series on D8 and R8, Android's new dexer and optimizer, respectively. For an intro to D8 read "Android's Java 8 support". For an intro to R8 read "R8 Optimization: Staticization". The previous post on R8 covered method outlining which automatically de-duplicated code. This was actually a detour from what I had promised was next at the end of the class constant operations post which preceded it. So let's get back on track. Class constant operations allow R8 to take calls such as MyActivity.class.getSimpleName() and replace it with the string literal "MyActivity". This was presented in the context of log tags, where you might write that expression instead of the string literal so that the tag always reflects the actual class name, even after obfuscation. This works great in a static context where the MyActivity.class literal is fixed, but it does not work when used on an instance. Instance reflection When dealing with an instance, the Class reference is obtained by calling getClass() instead of a MyActivity.class literal. This operation is not terribly expensive, but it is still a form of reflection. class MyActivity extends Activity { @Override void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); String name = this.getClass().getSimpleName(); Log.e(name, "Hello!"); } } The getClass() API is just a normal method on every Object and appears as a normal invoke-virtual in bytecode. [0003d0] MyActivity.onCreate:(Landroid/os/Bundle;)V 0000: invoke-super {v1, v2}, Landroid/app/Activity;.onCreate:(Landroid/os/Bundle;)V 0003: invoke-virtual {v1}, Ljava/lang/Object;.getClass:()Ljava/lang/Class; 0006: move-result-object v2 0007: invoke-virtual {v2}, Ljava/lang/Class;.getSimpleName:()Ljava/lang/String; 000a: move-result-object v2 Since R8 is performing whole-program analysis, it knows that there are no subtypes of MyActivity even though it's not marked as final. As a result, it can replace calls to this.getClass() with MyAct ## 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 ## R8 Optimization: Null Data Flow Analysis (Part 2) DevFeed: [R8 Optimization: Null Data Flow Analysis (Part 2)]() Original publisher: [Read original article]() Published: 2019-01-15T00:00:00Z Content type: article Language: en Sources: [Jake Wharton]() Topics: [Optimization](), [R8](), [Android](), [Kotlin](), [Compiler](), [Java]() Tags: [analysis](), [android](), [code](), [compiler](), [exception](), [generation](), [inlining](), [kotlin](), [optimization](), [r8](), [source](), [validation]() ### AI overview This article explains how R8 uses nullability information in its intermediate representation to perform null data flow analysis and optimize Kotlin code. It shows how R8 can simplify or eliminate null checks after method inlining, including defensive checks generated by the Kotlin compiler for public APIs. ### Source excerpt Note: This post is part of a series on D8 and R8, Android's new dexer and optimizer, respectively. For an intro to D8 read "Android's Java 8 support". For an intro to R8 read "R8 Optimization: Staticization". Part 1 of this post demonstrated R8's ability to eliminate null checks after method inlining. This was accomplished by virtue of nullability information being present in R8's (and D8's) intermediate representation (IR). When the arguments flowing into a method were always non-null or always null, the now-inlined null check can be computed at compile-time. Examples in the last two posts have mostly used Kotlin. To improve readability of their bytecode, I've been removing a section of it. The last post started with an example of a coalesce function being called from a main function. fun coalesce(a: T?, b: T?): T? = a ?: b fun main(args: Array) { println(coalesce("one", "two")) println(coalesce(null, "two")) } Multiple versions of the compiled bytecode of this function were shown in that post and they all started with sget-object v1, Ljava/lang/System;.out:Ljava/io/PrintStream;. This is the bytecode looking up the static System.out field on which it can eventually invoke the println method. If you compile, dex, and dump the bytecode of the Kotlin source above, however, the first bytecodes are something quite different. $ kotlinc *.kt $ java -jar d8.jar \ --lib $ANDROID_HOME/platforms/android-28/android.jar \ --release \ --output . \ *.class kotlin-stdlib-1.3.11.jar $ $ANDROID_HOME/build-tools/28.0.3/dexdump -d classes.dex [00023c] NullsKt.main:([Ljava/lang/String;)V 0000: const-string v0, "args" 0002: invoke-static {v2, v0}, Lkotlin/jvm/internal/Intrinsics;.checkParameterIsNotNull:(Ljava/lang/Object;Ljava/lang/String;)V 0005: sget-object v1, Ljava/lang/System;.out:Ljava/io/PrintStream; ... Instead of bytecodes representing the body of the function we wrote, the Kotlin compiler first emits a call to the standard library's Intrinstrics.checkParameter ## R8 Optimization: Null Data Flow Analysis (Part 1) DevFeed: [R8 Optimization: Null Data Flow Analysis (Part 1)]() Original publisher: [Read original article]() Published: 2018-12-18T00:00:00Z Content type: article Language: en Sources: [Jake Wharton]() Topics: [R8](), [Optimization](), [Kotlin](), [Android](), [Compiler](), [Code]() Tags: [analysis](), [android](), [code](), [compiler](), [inlining](), [kotlin](), [optimization](), [r8](), [ssa]() ### AI overview This article explains how R8 performs nullability data-flow analysis after inlining Kotlin functions. It uses an SSA-based intermediate representation to determine which branches are always taken or unreachable, enabling dead-code elimination and bytecode optimization. ### Source excerpt Note: This post is part of a series on D8 and R8, Android's new dexer and optimizer, respectively. For an intro to D8 read "Android's Java 8 support". For an intro to R8 read "R8 Optimization: Staticization". The last post in this series was the first to cover R8 and one of its optimizations. This post will cover an optimization which performs data flow analysis of nullability. Let's dig in! A coalesce function returns the first non-null argument that is provided. Running the following example, unsurprisingly, prints "one" and then "two". fun coalesce(a: T?, b: T?): T? = a ?: b fun main(vararg args: String) { println(coalesce("one", "two")) println(coalesce(null, "two")) } R8 and ProGuard will both perform function inlining when a function is small or if it's only called in one place. Since coalesce is small, its body will be inlined to every call site to be equivalent to the following source. fun main(vararg args: String) { println("one" ?: "two") println(null ?: "two") } Were this actual source, the Kotlin compiler will determine that both of the elvis operators (?:) can be determined at compile-time. Compiling and dexing that fake source produces two calls to println with "one" and "two" and zero conditionals. [000180] NullsKt.main:([Ljava/lang/String;)V 0000: sget-object v1, Ljava/lang/System;.out:Ljava/io/PrintStream; 0002: const-string v0, "one" 0004: invoke-virtual {v1, v0}, Ljava/io/PrintStream;.println:(Ljava/lang/Object;)V 0007: sget-object v1, Ljava/lang/System;.out:Ljava/io/PrintStream; 0009: const-string v0, "two" 000b: invoke-virtual {v1, v0}, Ljava/io/PrintStream;.println:(Ljava/lang/Object;)V 000e: return-void But since the inlining occurs inside of R8 and not prior to running the Kotlin compiler, the actual Dalvik bytecode contains the conditionals. [000144] NullsKt.main:([Ljava/lang/String;)V 0000: sget-object v1, Ljava/lang/System;.out:Ljava/io/PrintStream; 0002: const-string v0, "one" 0004: if-nez v0, 0006 0006: const-string v0, "two" 0 ## 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 ## How V8's compilation cache supports function inlining DevFeed: [How V8's compilation cache supports function inlining]() Original publisher: [Read original article]() Author: Wojtek Gawroński (afronski) Published: 2016-04-08T17:45:00Z Content type: article Language: en Sources: [Wojtek Gawroński]() Topics: [Compiler](), [V8](), [JavaScript](), [JIT](), [Optimization](), [Node.js]() Tags: [article](), [c-sharp](), [cache](), [canvas](), [clojure](), [compilation](), [compiler](), [css](), [css3](), [erlang](), [html](), [html5](), [inlining](), [javascript](), [mono](), [net](), [node-js](), [optimization](), [sicp](), [v8](), [vagrant](), [webgl]() ### AI overview This article explains why just-in-time compilation in V8 is difficult for JavaScript and discusses compilation caching as an optimization technique related to function inlining. It distinguishes compilation caches from inline caches. ### Source excerpt A mythical beast called JIT I have recently bumped into one of those articles which title sounds rather like "one weird trick" ad. Guiding just from it, you can imagine how small amount of information is contained there, and by actually going through that link there you will definitely make sure that it has some knowledge, but no real explanations are in place. Of course, a final explanation is indeed really simple - Function.prototype.toString() returns everything even the comments inside the function body, size of that string is a feature that allows the optimizing compiler inside V8 to make a decision to inline that particular function or not. There is even a command line switch which to use to modify a limit and a default value. Simple enough? Not really. That article left a lot of unanswered questions. Probably because of that JIT compilers and its optimization techniques are kind of black magic. Why is it hard? Obviously compiler engineers are not dumb people (they are actually really smart) and they are not obfuscating and complicating this by accident or on purpose. They are working hard, especially with such weakly typed and underspecified languages like JavaScript to provide you an optimized version of your code. Why is it a hard job? It is all about guarantees. How many of them you can recall from memory when it comes to JavaScript? Not a lot of them, right? That is not good, especially from the perspective of a compiler engineer. JavaScript is everywhere, success of the internet spread this language, and nowadays success of Node.js pushed this language from front-end, even to server-side - and everywhere people are talking about performance. Obviously not about native like performance for scientific computations, but the more complexity is pushed to the application layer, the more of it will have to be optimized after all. That's why compilers and their creators have to be smart people - they have to deal with complexity of your applications and "illness ## 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 ## Invoke Interface Optimisations DevFeed: [Invoke Interface Optimisations]() Original publisher: [Read original article]() Author: Martin Thompson (noreply@blogger.com) Published: 2012-04-29T10:22:00Z Content type: tutorial Language: en Sources: [Mechanical Sympathy]() Topics: [Java](), [Code](), [Compiler]() Tags: [code](), [inlining](), [intel](), [java](), [jvm](), [kernel](), [linux](), [optimisations](), [performance](), [processor]() ### AI overview This article explains how the HotSpot JVM dynamically inlines methods at runtime, including methods invoked through interfaces and overridden methods. It describes the relevant Java bytecode instructions and presents benchmark results from a Linux system using Oracle's Java 1.7.0_02 server JVM. ### Source excerpt I'm often asked about the performance differences between Java, C, and C++, and which is better. As with most things in life there is no black and white answer. A lot is often discussed about how managed runtime based languages offer less performance than their statically compiled compatriots. There are however a few tricks available to managed runtimes that can provide optimisation opportunities not available to statically optimised languages. One such optimisation available to the runtime is to dynamically inline a method at the call site. Many would say inlining is *the* major optimisation of dynamic languages. This is an approach whereby the function/method call overhead can be avoided and further optimisations enabled. Inlining can easily be done at compile, or run, time for static or private methods of a class because they cannot be overridden. It can also be done by Hotspot at run time which is way more interesting. In bytecode the runtime will see invokestatic and invokespecial opcodes for static and private methods respectively. Methods that involve late binding, such as interface implementations and method overriding, appear as the invokeinterface and invokevirtual opcodes respectively. At compile time it is not possible to determine how many implementations there will be for an interface, or how many classes will override a base method. The compiler can have some awareness but just how do you deal with dynamically loaded classes via Class.forName("x").newInstance()? The Hotspot runtime is very smart. It can track all classes as they are loaded and apply appropriate optimisations to give the best possible performance for our code. One such approach is dynamic inlining at the call site which we will explore. Code public interface Operation { int map(int value); } public class IncOperation implements Operation { public int map(final int value) { return value + 1; } } public class DecOperation implements Operation { public int map(final int value) { return va