[{"content":"NVIDIA offers free access to their powerful Nemotron models through their NVIDIA Build platform. In this post, I’ll walk you through how to get a free API key and configure it in VS Code to use models like nvidia\/nemotron-3-ultra-550b-a55b directly in VS Code. Also you can choose any other model from here.\nPrerequisites VScode needs to be above 1.27 it needs to have customendpoint supporting\nGetting Your Free NVIDIA API Key Go to build.nvidia.com Sign in or create an NVIDIA account Navigate to the model you want to use (e.g., Nemotron 3 Ultra) Click “Get API Key” button Note: In my experience, the “Get API Key” button in the UI didn’t work properly (it appeared to do nothing). If this happens to you, here’s how to get your API key:\nOpen your browser’s Developer Tools (F12) \u2192 Network tab Click the “Get API Key” button again Look for a POST request to https:\/\/api.nvcf.nvidia.com\/v2\/nvcf\/api-keys Click on that request and check the Response tab - you’ll find your API key there The API call looks like this (for reference - you don’t need to run this manually):\n# This is what the UI calls behind the scenes - for reference only curl 'https:\/\/api.nvcf.nvidia.com\/v2\/nvcf\/api-keys' \\ -H 'Accept: *\/*' \\ -H 'Accept-Language: en-GB,en;q=0.9' \\ -H 'Accept-Encoding: gzip, deflate, br, zstd' \\ -H 'Referer: https:\/\/build.nvidia.com\/' \\ -H 'content-type: application\/json' \\ -H 'Origin: https:\/\/build.nvidia.com' \\ -H 'Connection: keep-alive' \\ -H 'Cookie: ...' \\ -H 'Sec-Fetch-Dest: empty' \\ -H 'Sec-Fetch-Mode: cors' \\ -H 'Sec-Fetch-Site: same-site' \\ --data-raw '{"name":"","type":"AI_PLAYGROUNDS_KEY","expiryDate":"2027-01-19T11:37:44Z","policies":[{"product":"nv-cloud-functions","scopes":["invoke_function"],"resources":[{"id":"*","type":"account-functions"}]}]}' The response will contain your API key:\n{ "apiKey": { "keyId": "1a9e12d7-b35f-4ed0-943c-3935c442a5c9", "name": "NVIDIABuild-Autogen-54", "type": "AI_PLAYGROUNDS_KEY", "value": "nvapi-...", "ownerId": "...", "status": "ACTIVE", "expiryDate": "2027-01-19T11:37:44.000Z", "createdDate": "2026-07-19T11:39:27.197Z", "policies": [ { "product": "nv-cloud-functions", "productDisplayName": "NVIDIA Cloud Functions", "resources": [ { "id": "*", "type": "account-functions" }, { "id": "*", "type": "authorized-functions" } ], "roles": [], "scopes": [ "invoke_function", "list_functions", "list_functions_details", "queue_details" ] }, { "product": "ai-foundations", "productDisplayName": "Public API Endpoints" }, { "product": "artifact-catalog", "productDisplayName": "NGC Catalog" }, { "product": "private-registry", "productDisplayName": "NVIDIA Private Registry" } ] } } Important: Save the value field (the nvapi-... key) - you’ll need it for VS Code configuration.\nConfiguring VS Code The recommended way is to use the VS Code UI to add the custom model, which will properly encrypt and store your API key. Custom language models are configured in a separate file called chatLanguageModels.json (not in settings.json under chat.mcp.servers - that’s for MCP servers, which is a different feature).\nUsing VS Code UI Check the video if you have not done before. Below are the steps\nOpen VS Code Command Palette (Cmd\/Ctrl + Shift + P) Search for “Chat: Manage Language Models” here the docs Click “Add Model” or “Add Custom Model” Fill in the details: Name: Nvidia (or any name you prefer) Vendor: customendpoint API Key: Enter your nvapi-... key (VS Code will encrypt and store it securely) Model ID: nvidia\/nemotron-3-ultra-550b-a55b Model Name: nvidia\/nemotron-3-ultra-550b-a55b URL: https:\/\/integrate.api.nvidia.com\/v1\/chat\/completions Tool Calling: \u2705 Enabled Max Input Tokens: 262144 Max Output Tokens: 32000 in chatLanguageModels.json will have json like below\n[ { "name": "Nvidia", "vendor": "customendpoint", "apiKey": "${input:chat.lm.secret.6878c97f}", "models": [ { "id": "nvidia\/nemotron-3-ultra-550b-a55b", "name": "nvidia\/nemotron-3-ultra-550b-a55b", "url": "https:\/\/integrate.api.nvidia.com\/v1\/chat\/completions", "toolCalling": true, "vision": false, "maxInputTokens": 262144, "maxOutputTokens": 32000 } ] } ] Using the Model in VS Code Once configured, you can use the model in VS Code Chat:\nOpen the Chat view (Ctrl+Alt+I \/ Cmd+Option+I) Click the model selector dropdown Select “Nvidia” \u2192 “nvidia\/nemotron-3-ultra-550b-a55b” (or whatever name you gave the model) Start chatting! The model supports:\nTool calling - Can use tools and functions 128K context window - Large context for long conversations 16K output tokens - Long responses Model Details Property Value Model ID nvidia\/nemotron-3-ultra-550b-a55b Endpoint https:\/\/integrate.api.nvidia.com\/v1\/chat\/completions Context Window 128,000 tokens Max Output 16,000 tokens Tool Calling \u2705 Yes Free Tier \u2705 Yes (with NVIDIA account) Tips Rate Limits: The free tier has rate limits. Check NVIDIA’s documentation for current limits. API Key Expiry: The key expires on the date shown in the response (e.g., 2027-01-19). You’ll need to generate a new one when it expires. Multiple Models: You can add multiple NVIDIA models to the same configuration by adding more entries to the models array. VS Code Insiders: If you’re on VS Code Insiders, the settings path might be slightly different. Resources NVIDIA Build Platform Nemotron 3 Ultra Model Card NVIDIA API Documentation VS Code Copilot Custom Models Documentation All free model from Nvidia Happy coding with NVIDIA’s free models! \ud83d\ude80\n","permalink":"https:\/\/ozkanpakdil.github.io\/posts\/my_collections\/2026\/2026-07-19-how-to-add-nvidia-free-model\/","summary":"

NVIDIA offers free access to their powerful Nemotron models through their NVIDIA Build platform<\/a>. In this post, I’ll walk you through how to get a free API key and configure it in VS Code to use models like nvidia\/nemotron-3-ultra-550b-a55b<\/code> directly in VS Code. Also you can choose any other model from here<\/a>.<\/p>\n

Prerequisites<\/h3>\n

VScode needs to be above 1.27 it needs to have customendpoint supporting<\/p>\n

Getting Your Free NVIDIA API Key<\/h2>\n
    \n
  1. Go to build.nvidia.com<\/a><\/li>\n
  2. Sign in or create an NVIDIA account<\/li>\n
  3. Navigate to the model you want to use (e.g., Nemotron 3 Ultra<\/a>)<\/li>\n
  4. Click “Get API Key” button<\/li>\n<\/ol>\n

    Note<\/strong>: In my experience, the “Get API Key” button in the UI didn’t work properly (it appeared to do nothing). If this happens to you, here’s how to get your API key:<\/p>","title":"How to add NVIDIA free models to VS Code"},{"content":"In the world of software engineering, we often obsess over the “Testing Pyramid.” We pour resources into unit tests, integration tests, and E2E suites. These are critical, they tell us that our features work as designed. But there\u2019s a shadowy category of bugs that traditional tests often miss: the architectural “anti-patterns” and “API misuses” that don’t break functionality today but lead to system failures, memory leaks, or portability issues tomorrow.\nThis is where Code Hygiene comes in.\nWhat is Code Hygiene? Code Hygiene is the practice of using automated tools to enforce non-functional constraints, coding standards, and safety patterns across a codebase. Unlike a unit test that checks if Add(1, 1) == 2, a hygiene scanner checks if you\u2019re using an API in a way that\u2019s technically “valid” but practically dangerous.\nIn Computer Science, this is formally known as Static Program Analysis. While general “linting” catches stylistic issues, Code Hygiene focuses on domain-specific safety and architectural integrity.\nThe Evolution: From API Safety to Platform Portability One of the most powerful applications of code hygiene I\u2019ve ever implemented involved managing a high-stakes support matrix. We had a system that executed various Linux commands across a wide range of distributions: Ubuntu, SUSE, and RedHat, all in different versions.\nThe Problem: The Command Parameter Minefield As Linux distributions evolve, command-line parameters change. A flag that works on Ubuntu 20.04 might be deprecated on RedHat 9, or worse, behave subtly differently. Standard CI runs on a single OS wouldn’t catch these issues until a customer on a specific RedHat version hit a runtime error.\nThe Solution: Static Analysis + Testcontainers To solve this, I developed a two-tier hygiene strategy:\nThe Scanner: We built a custom static analysis tool to crawl through the codebase and identify every single exec or shell-out call. The Matrix Validation: Using Testcontainers with C#, we spun up the exact versions of Ubuntu, SUSE, and RedHat defined in our support matrix. We then fed the commands discovered by our scanner into these containers to verify their exit codes and behavior. This “Hygiene for Portability” transformed our release process. We stopped guessing if our commands were compatible and started knowing.\nCase Study: The “Order of Operations” Leak Hygiene isn’t just for external commands; it\u2019s for internal APIs too. Recently, I dealt with a scenario where a database library had a specific requirement: BeginTransaction() had to be called after certain context configurations, but before others.\nSyntactically, the code db.WithContext(ctx).Begin() looked fine. It compiled. It even passed unit tests. However, in tests, it caused intermittent memory leaks because the context wasn’t being associated with the transaction object correctly.\nA simple AST (Abstract Syntax Tree) scanner fixed this permanently. We wrote a rule that flags any instance where these calls are out of order. Institutional knowledge was turned into an automated gatekeeper.\n\/\/ Using Go's AST (Abstract Syntax Tree) to detect out-of-order method calls. \/\/ This identifies 'db.WithContext(ctx).Begin()' which should be 'db.Begin().WithContext(ctx)'. insp.Preorder([]ast.Node{(*ast.CallExpr)(nil)}, func(n ast.Node) { call := n.(*ast.CallExpr) \/\/ Check if the outer function call is "Begin" outerSel, ok := call.Fun.(*ast.SelectorExpr) if !ok || outerSel.Sel.Name != "Begin" { return } \/\/ Ensure we are calling Begin on a *gorm.DB or result of WithContext on gorm.DB if !isGormDB(pass, outerSel.X) { return } \/\/ Check if "Begin" was called on the result of another function innerCall, ok := outerSel.X.(*ast.CallExpr) if !ok { return } \/\/ Check if that inner function call was "WithContext" innerSel, ok := innerCall.Fun.(*ast.SelectorExpr) if ok && innerSel.Sel.Name == "WithContext" { pass.Reportf(call.Pos(), "Hygiene Alert: Use 'db.Begin().WithContext(ctx)' to prevent leaks.") } }) Why You Need a Hygiene Strategy Preventing “Silent” Failures: Catch memory leaks, race conditions, and API misuses that don’t trigger a test failure but kill performance. Institutional Memory: When a team learns a hard lesson, a hygiene rule ensures that new developers (or your future self) don’t repeat the mistake. Scalable Reviews: Humans are bad at spotting subtle pattern errors in 1,000-line PRs. Computers are perfect at it. Platform Confidence: In a world of multi-arch and multi-OS support, scanners can validate that your code respects the constraints of every target environment. Conclusion Testing tells you the code is right. Hygiene tells you the code is healthy.\nBy integrating custom static analysis and matrix-based validation into your workflow, you move from a reactive “hotfix” stance to a proactive “preventative” culture. It\u2019s time to look beyond functionality and start caring about the structural health of your codebase.\n","permalink":"https:\/\/ozkanpakdil.github.io\/posts\/my_collections\/2026\/2026-04-22-code-hygiene\/","summary":"

    In the world of software engineering, we often obsess over the “Testing Pyramid.” We pour resources into unit tests, integration tests, and E2E suites. These are critical, they tell us that our features work as designed. But there\u2019s a shadowy category of bugs that traditional tests often miss: the architectural “anti-patterns” and “API misuses” that don’t break functionality today but lead to system failures, memory leaks, or portability issues tomorrow.<\/p>","title":"Beyond Functionality: Why Code Hygiene is Your Project's Immune System"},{"content":"After setting up CUDA on my other laptop, I moved to a different(older) machine that doesn’t have an NVIDIA GPU. This one is an everyday laptop with integrated Intel graphics, but that doesn’t mean we have to settle for slow CPU-only performance.\nOn this machine, I switched to the Vulkan backend for llama.cpp and the results were even more dramatic than I expected.\nMachine Hardware Info This laptop is running Debian 13 (Trixie\/Sid) with the following specs:\nCPU: Intel(R) Core(TM) i5-8250U @ 1.60GHz (4 Cores, 8 Threads) GPU: Intel(R) UHD Graphics 620 (Integrated) RAM: 8 GB OS: Debian GNU\/Linux 13 (trixie) Kernel: 6.12.74+deb13+1-amd64 The Performance Gap: CPU vs. Vulkan I tested both the Qwen 3.5 2B and the more capable Qwen 2.5 3B models (GGUF format) to see how the integrated Intel GPU handles different LLM sizes.\nModel Setup Response Time (Eval) Total Time Tokens\/sec Notes Qwen 3.5 2B CPU Only ~7 minutes (428s) 431s 2.32 Purely on i5-8250U Qwen 3.5 2B Vulkan 14 seconds 21s 6.07 30x improvement! Qwen 2.5 3B Vulkan 47 seconds 52s 4.54 More capable reasoning The 14-second response vs. 7 minutes on the 2B model is a game-changer, but the 3B model (answering “write me hello world in rust” in 47 seconds) is the “sweet spot” for this machine. While the 2B model can be fully offloaded, the 3B model is too large to fit entirely in the GPU’s shared memory, but it still performs admirably.\nCompiling llama.cpp with Vulkan Compiling for Vulkan on Debian is straightforward but requires the right development headers. It took me about 10 minutes to finish the compilation.\nFirst, ensure you have the Vulkan development packages:\nsudo apt update sudo apt install libvulkan-dev vulkan-tools Then, compile llama.cpp using CMake with the Vulkan option enabled:\ncmake -B build -DGGML_VULKAN=ON cmake --build build --config Release Running with Vulkan Acceleration Once compiled, you can run llama-server (or llama-cli). The server will automatically detect your Vulkan-compatible devices.\n.\/build\/bin\/llama-server -hf unsloth\/Qwen3.5-2B-GGUF --jinja -c 4096 --host 127.0.0.1 --port 8033 In the logs, you’ll see it picking up the Intel UHD Graphics. For the 2B model, I was able to offload all 25 layers:\nggml_vulkan: Found 1 Vulkan devices: ggml_vulkan: 0 = Intel(R) UHD Graphics 620 (KBL GT2) (Intel open-source Mesa driver) | uma: 1 | fp16: 1 | ... ... load_tensors: offloading 23 repeating layers to GPU load_tensors: offloaded 25\/25 layers to GPU Pushing the Limits: Qwen 2.5 3B When I moved to the 3.4B parameter model (Qwen2.5-3B-Instruct-Q4_K_M), the memory management became more complex. The system had to balance between the GPU’s shared memory and the CPU:\nllama_params_fit_impl: projected to use 2283 MiB of device memory vs. 2200 MiB of free device memory llama_params_fit_impl: cannot meet free memory target of 1024 MiB, need to reduce device memory by 1106 MiB llama_params_fit_impl: filling dense layers back-to-front: llama_params_fit_impl: - Vulkan0 (Intel(R) UHD Graphics 620 (KBL GT2)): 13 layers, 1137 MiB used, 1062 MiB free ... load_tensors: offloaded 13\/37 layers to GPU Even though it only offloaded 13\/37 layers to the GPU, it still maintained a respectable 4.54 tokens\/sec. This shows that even partial offloading on integrated graphics provides a significant boost over pure CPU execution for larger models.\nSummary & Next Steps If you don’t have an NVIDIA card, don’t ignore your integrated GPU. Vulkan provides a fantastic alternative that works out-of-the-box on Debian with Intel and AMD hardware.\nMy next target is to use Qwen on OpenClaw to further explore local LLM capabilities. Stay tuned!\nReference:\nhttps:\/\/en.wikipedia.org\/wiki\/Vulkan Vulkan: https:\/\/vulkan.lunarg.com\/ https:\/\/github.com\/ggml-org\/llama.cpp\/blob\/master\/docs\/build.md#vulkan llama.cpp: https:\/\/github.com\/ggml-org\/llama.cpp\/ ","permalink":"https:\/\/ozkanpakdil.github.io\/posts\/my_collections\/2026\/2026-03-22-vulkan-llamacpp-debian-13\/","summary":"

    After setting up CUDA on my other laptop, I moved to a different(older) machine that doesn’t have an NVIDIA GPU. This one is an everyday laptop with integrated Intel graphics, but that doesn’t mean we have to settle for slow CPU-only performance.<\/p>\n

    On this machine, I switched to the Vulkan<\/strong> backend for llama.cpp<\/code> and the results were even more dramatic than I expected.<\/p>\n

    Machine Hardware Info<\/h3>\n

    This laptop is running Debian 13 (Trixie\/Sid)<\/strong> with the following specs:<\/p>","title":"Accelerating LLMs on Debian 13: Setting up Vulkan for llama.cpp"},{"content":"Setting up NVIDIA CUDA on Debian 13 (Trixie\/Sid) to run Large Language Models (LLMs) can be a bit of a journey, especially if you’re transitioning from the default open-source drivers to the proprietary stack required for GPGPU workloads.\nOver the last few days, I’ve been working on getting llama.cpp to run with CUDA on my laptop to see how much of a difference it makes compared to pure CPU execution.\nInitially, I tested a 35B model on macOS, where it was responding in about 17 seconds. When I moved that same 35B model to my old laptop running Debian 13 (on CPU), the response time plummeted to 4 minutes and 30 seconds. This massive gap was my main motivation to try and enable CUDA on the laptop’s GPU.\nThe Problem: Nouveau vs. Proprietary Drivers By default, Debian might use the open-source nouveau driver. While great for basic display tasks, it doesn’t support CUDA. To run llama-server with GPU acceleration, you need the official NVIDIA drivers and the CUDA toolkit.\nI followed the NVIDIA Tesla Driver Installation Guide for Debian, which is a critical resource for getting the right packages.\nOne specific hurdle with Secure Boot enabled was the need to trust the DKMS-generated keys:\nsudo mokutil --import \/var\/lib\/dkms\/mok.pub After a reboot and enrolling the key in the MOK manager, the driver was finally active and recognized by the system.\nCompiling llama.cpp with CUDA Support Once the drivers and nvcc were ready, I recompiled llama.cpp with CUDA enabled (see the official CUDA build documentation for more details).\nThe compilation process is quite resource-intensive and took about 15 minutes on my laptop:\nexport CUDACXX=\/usr\/local\/cuda\/bin\/nvcc export CUDA_HOME=\/usr\/local\/cuda cmake -B build -DGGML_CUDA=ON cmake --build build --config Release The VRAM Reality Check (OOM Errors) My laptop has an NVIDIA GeForce MX450 with 2 GB of VRAM. This is quite modest for modern LLMs.\nInitially, I tried running that 35B model that was so slow on the CPU:\nllama-server -hf unsloth\/Qwen3.5-35B-A3B-GGUF --jinja -c 16384 --host 127.0.0.1 --port 8033 It failed with a cudaMalloc failed: out of memory error. Looking at the logs:\nModel parameters: ~857 MiB Context\/CLIP buffers: ~899 MiB Total requested: > 1.7 GB With the OS and display driver already taking up some of that 2 GB, there just wasn’t enough room. The 35B model was simply too large for this specific hardware’s VRAM. Even though CUDA would have been faster than the CPU-only 4.5 minutes, the hardware limit forced me to pivot.\nThe Result: 2B Model Benchmark I switched to a smaller 2B model to stay within the VRAM limits. The results were impressive and clearly showed why we go through this trouble.\nAsking Qwen 2B to “write me hello world in rust”:\nSetup Time to Complete Notes CPU Only 1 minute 32 seconds Default nouveau or no acceleration Vulkan (GPU) 57 seconds Using -ngl 2 and -dev Vulkan1 CUDA (GPU) 24 seconds Best performance (4x over CPU) That’s nearly a 4x speed improvement on a entry-level mobile GPU when using CUDA! Interestingly, Vulkan also provides a significant boost over CPU-only mode, though it falls short of CUDA’s optimization for this hardware.\nThe Vulkan Alternative I also experimented with the Vulkan backend to see how it compares. While CUDA remains the king of performance for NVIDIA hardware, Vulkan is a great cross-platform alternative.\nTo run the Vulkan version, I used the following command:\n.\/build\/bin\/llama-server -hf unsloth\/Qwen3.5-2B-GGUF --jinja -c 4096 -ngl 2 -dev Vulkan1 --host 127.0.0.1 --port 8033 Important Note on Vulkan: I encountered some memory-related segmentation faults when trying to offload too many layers. I had to limit the offloading to -ngl 2 to maintain stability. Even with this limitation, it finished the task in 57 seconds, which is still much better than the 1m 32s on the CPU.\nWhen starting up, llama.cpp detected multiple devices, including the integrated Intel graphics and the MX450:\nggml_vulkan: Found 2 Vulkan devices: ggml_vulkan: 0 = Intel(R) Iris(R) Xe Graphics (TGL GT2) (Intel open-source Mesa driver) | uma: 1 | ... ggml_vulkan: 1 = NVIDIA GeForce MX450 (NVIDIA) | uma: 0 | fp16: 1 | bf16: 0 | warp size: 32 | ... Interestingly, it also gave some advice on how to improve performance for this specific hardware:\nThe following devices will have suboptimal performance due to a lack of tensor cores: Device 0: NVIDIA GeForce MX450 Consider compiling with CMAKE_CUDA_ARCHITECTURES=61-virtual;80-virtual and DGGML_CUDA_FORCE_MMQ to force the use of the Pascal code for Turing. Here is what the logs look like when it’s balancing the memory:\nllama_params_fit_impl: projected to use 926 MiB of device memory vs. 1906 MiB of free device memory llama_params_fit_impl: cannot meet free memory target of 1024 MiB, need to reduce device memory by 43 MiB llama_params_fit_impl: context size set by user to 4096 -> no change llama_params_fit: failed to fit params to free device memory: n_gpu_layers already set by user to 2, abort ... load_tensors: offloading 1 repeating layers to GPU load_tensors: offloaded 2\/25 layers to GPU load_tensors: CPU_Mapped model buffer size = 1179.54 MiB load_tensors: Vulkan1 model buffer size = 429.35 MiB And the final timing results:\nprompt eval time = 3065.78 ms \/ 16 tokens ( 191.61 ms per token, 5.22 tokens per second) eval time = 57813.32 ms \/ 764 tokens ( 75.67 ms per token, 13.21 tokens per second) total time = 60879.11 ms \/ 780 tokens Summary While the setup can be “so complicated” (dealing with drivers, Secure Boot, and compilation), the performance gains are undeniable. Even on a low-end GPU like the MX450, offloading the heavy lifting to CUDA makes the local LLM experience much more interactive.\nBonus: NVIDIA GPU Diagnostic Script To help troubleshoot my setup, I wrote a small script nvidia_check_and_run.sh to verify the driver, kernel modules, and llama.cpp support.\n#!\/bin\/bash # Configuration LLAMA_PATH="\/nix\/store\/wr7vi3957cx751la7q490h9v2m6q71fm-llama-cpp-8255\/bin" LLAMA_SERVER="$LLAMA_PATH\/llama-server" LLAMA_BENCH="$LLAMA_PATH\/llama-bench" LLAMA_CLI="$LLAMA_PATH\/llama-cli" echo "--- NVIDIA GPU Diagnostic ---" # 1. Check for the NVIDIA device via PCI echo "[1\/4] Checking PCI devices for NVIDIA GPU..." if lspci | grep -i nvidia; then echo " - NVIDIA hardware detected via lspci." else echo " - No NVIDIA hardware found on PCI bus." fi # 2. Check for the driver status echo -e "\\n[2\/4] Checking NVIDIA driver status..." if command -v nvidia-smi &> \/dev\/null; then echo " - nvidia-smi found. Running..." if ! nvidia-smi; then echo " - CRITICAL: nvidia-smi failed. Kernel modules might not be loaded." echo " - ACTION: Try running 'sudo modprobe nvidia' and then 'nvidia-smi' again." fi else echo " - nvidia-smi NOT found. Driver might not be installed or active." fi # 3. Check for the kernel modules echo -e "\\n[3\/4] Checking for loaded NVIDIA kernel modules..." if \/sbin\/lsmod | grep -i nvidia &> \/dev\/null; then echo " - NVIDIA kernel modules are loaded." \/sbin\/lsmod | grep -i nvidia else echo " - CRITICAL: No NVIDIA kernel modules loaded." echo " - ACTION: Run 'sudo modprobe nvidia' to load the driver." fi # 4. Check for llama.cpp device support echo -e "\\n[4\/4] Checking llama.cpp device support..." if [ -f "$LLAMA_CLI" ]; then echo " - Checking llama-cli with -ngl flag..." "$LLAMA_CLI" -ngl 1 --version else echo " - llama-cli not found at $LLAMA_CLI" fi Running this script gave me a clear picture of what was missing:\n--- NVIDIA GPU Diagnostic --- [1\/4] Checking PCI devices for NVIDIA GPU... 0000:01:00.0 3D controller: NVIDIA Corporation TU117M [GeForce MX450] (rev a1) - NVIDIA hardware detected via lspci. [2\/4] Checking NVIDIA driver status... - nvidia-smi found. Running... Fri Mar 20 01:55:51 2026 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 595.45.04 Driver Version: 595.45.04 CUDA Version: 13.2 | +-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage\/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 NVIDIA GeForce MX450 On | 00000000:01:00.0 Off | N\/A | | N\/A 53C P8 N\/A \/ 5001W | 5MiB \/ 2048MiB | 0% Default | | | | N\/A | +-----------------------------------------+------------------------+----------------------+ [3\/4] Checking for loaded NVIDIA kernel modules... - NVIDIA kernel modules are loaded. ... [4\/4] Checking llama.cpp device support... - Checking llama-cli with -ngl flag... warning: no usable GPU found, --gpu-layers option will be ignored warning: one possible reason is that llama.cpp was compiled without GPU support ... If you are on Debian 13 and want to try this, make sure you check your VRAM limits before picking a model, and don’t forget that mokutil step if you have Secure Boot enabled!\nReference:\nNVIDIA Tesla Driver Installation Guide for Debian llama.cpp: https:\/\/github.com\/ggml-org\/llama.cpp\/ ","permalink":"https:\/\/ozkanpakdil.github.io\/posts\/my_collections\/2026\/2026-03-20-cuda-llamacpp-debian-13\/","summary":"

    Setting up NVIDIA CUDA on Debian 13 (Trixie\/Sid) to run Large Language Models (LLMs) can be a bit of a journey, especially if you’re transitioning from the default open-source drivers to the proprietary stack required for GPGPU workloads.<\/p>\n

    Over the last few days, I’ve been working on getting llama.cpp<\/code> to run with CUDA on my laptop to see how much of a difference it makes compared to pure CPU execution.<\/p>","title":"Accelerating LLMs on Debian 13: Setting up CUDA for llama.cpp"},{"content":" Note: These are suggested optimizations I have not personally tried yet. I’m blogging them as I’m planning to test them throughout this week.\nOrbStack is highly optimized for macOS, using a proprietary, high-performance networking stack and a custom VirtioFS implementation with aggressive caching. Podman, while being open-source and standard-compliant, can be tuned to significantly bridge the performance gap.\nThe following plan outlines key areas where Podman’s performance can be improved on macOS:\n1. Enable Rosetta 2 for x86_64 Emulation (Apple Silicon only) If you are on an Apple Silicon (M1\/M2\/M3\/M4) Mac, running x86_64 containers is often much slower than ARM64. Podman supports Apple’s native Rosetta 2 for Linux, which is substantially faster than QEMU-based emulation.\nCheck if Rosetta is enabled: Run podman machine inspect and look for "Rosetta": true. Enable Rosetta: When creating a new machine, use the --rosetta flag (if your Podman version and macOS version support it, typically macOS 13+): podman machine init --rosetta Note: If you have an existing machine, you may need to recreate it to enable Rosetta. 2. Optimize Volume Mounting (VirtioFS) Podman uses virtiofs by default on macOS, which is the fastest way to share files between the host and the VM using Apple’s Virtualization.framework. However, file system I\/O can still be a bottleneck.\nAvoid Deeply Nested Mounts: Minimize the number of files synced by mounting only the necessary sub-directories instead of the entire home directory. Use Named Volumes: For high-I\/O workloads (like database storage or node_modules), use named volumes instead of bind mounts. Named volumes reside within the VM’s disk image and operate at near-native speeds. podman volume create my-data podman run -v my-data:\/app\/data ... 3. Tuning Resource Allocation Ensure the Podman machine has sufficient resources. The default settings might be conservative for demanding workloads.\nIncrease CPUs and Memory: Adjust the machine’s resources to match your workload. podman machine set --cpus 4 --memory 8192 (Requires the machine to be stopped: podman machine stop) 4. Networking Performance (gvproxy) Podman uses gvproxy for user-mode networking. This is often the primary reason OrbStack feels faster for network-heavy tasks, as OrbStack uses a more direct networking approach.\nReduce Network Hops: If possible, avoid complex port mappings or heavy network traffic through the user-mode proxy. MTU Tuning: In some environments, increasing the MTU within the container can improve throughput, though this is dependent on the host’s network configuration. 5. Experiment with the libkrun Provider Podman on macOS supports multiple virtualization backends. While applehv (default) is stable, libkrun (based on krun) can sometimes offer better performance for specific workloads, especially those involving GPU acceleration or specialized Virtio devices.\nTry libkrun: You can initialize a machine with the libkrun provider: podman machine init --provider libkrun 6. Summary of Recommended Configuration for Speed To get the best performance today, use the following initialization command (on Apple Silicon):\n# Stop and remove existing machine if necessary podman machine stop podman machine rm # Initialize with optimized settings podman machine init \\ --cpus 4 \\ --memory 8192 \\ --disk-size 50 \\ --rosetta \\ --rootful=false By applying these optimizations, Podman’s performance on macOS will be significantly closer to OrbStack, especially for CPU-intensive emulation and file-system heavy development workflows.\nHappy containerizing!\n","permalink":"https:\/\/ozkanpakdil.github.io\/posts\/my_collections\/2026\/2026-03-08-tuning-podman-macos-performance\/","summary":"

    \n

    Note:<\/strong> These are suggested optimizations I have not personally tried yet. I’m blogging them as I’m planning to test them throughout this week.<\/p><\/blockquote>\n

    OrbStack is highly optimized for macOS, using a proprietary, high-performance networking stack and a custom VirtioFS implementation with aggressive caching. Podman, while being open-source and standard-compliant, can be tuned to significantly bridge the performance gap.<\/p>\n

    The following plan outlines key areas where Podman’s performance can be improved on macOS:<\/p>","title":"Tuning Podman on macOS to Match OrbStack Performance"},{"content":"I have been using Atlassian MCP with internal Confluence and Jira, and it has been wonderful.\nFinding internal information is often challenging and time-consuming. To be honest, searching through Jira or Confluence and locating the right information can be really difficult.\nCreate Jira and Confluence API tokens from your internal site profile page. For example: https:\/\/internalconfluence.company.com\/profile\/personal for Confluence and https:\/\/jira.company.com\/secure\/admin\/CreateAPIToken!default.jspa for Jira. These URLs may vary depending on your setup. Create an mcp.json file in the .vscode folder for Visual Studio Code, or place this MCP configuration in the appropriate folder for your IDE of choice: { "mcpServers": { "mcp-atlassian": { "command": "uvx", "args": ["mcp-atlassian"], "env": { "JIRA_URL": "https:\/\/jira.company.com", "JIRA_USERNAME": "your.email@company.com", "JIRA_API_TOKEN": "your_api_token", "CONFLUENCE_URL": "https:\/\/internalconfluence.company.com\/wiki", "CONFLUENCE_USERNAME": "your.email@company.com", "CONFLUENCE_API_TOKEN": "your_api_token" } } } } Remember to run podman-desktop or docker desktop. Because this MCP works as a docker container.\nAfter that, open GitHub Copilot in your IDE and instruct it to use the Atlassian MCP to search Confluence and Jira. This makes finding internal information incredibly easy\u2014it goes through pages systematically and retrieves all the details you need.\n","permalink":"https:\/\/ozkanpakdil.github.io\/posts\/my_collections\/2026\/2026-02-08-atlassian-mcp\/","summary":"

    I have been using Atlassian MCP<\/a> with internal Confluence and Jira, and it has been wonderful.<\/p>\n

    Finding internal information is often challenging and time-consuming. To be honest, searching through Jira or Confluence and locating the right information can be really difficult.<\/p>\n

      \n
    1. Create Jira and Confluence API tokens from your internal site profile page. For example: https:\/\/internalconfluence.company.com\/profile\/personal<\/code> for Confluence and https:\/\/jira.company.com\/secure\/admin\/CreateAPIToken!default.jspa<\/code> for Jira. These URLs may vary depending on your setup.<\/li>\n
    2. Create an mcp.json<\/code> file in the .vscode<\/code> folder for Visual Studio Code, or place this MCP configuration in the appropriate folder for your IDE of choice:<\/li>\n<\/ol>\n
      {\n<\/span><\/span>  "mcpServers"<\/span>: {\n<\/span><\/span>    "mcp-atlassian"<\/span>: {\n<\/span><\/span>      "command"<\/span>: "uvx"<\/span>,\n<\/span><\/span>      "args"<\/span>: ["mcp-atlassian"<\/span>],\n<\/span><\/span>      "env"<\/span>: {\n<\/span><\/span>        "JIRA_URL"<\/span>: "https:\/\/jira.company.com"<\/span>,\n<\/span><\/span>        "JIRA_USERNAME"<\/span>: "your.email@company.com"<\/span>,\n<\/span><\/span>        "JIRA_API_TOKEN"<\/span>: "your_api_token"<\/span>,\n<\/span><\/span>        "CONFLUENCE_URL"<\/span>: "https:\/\/internalconfluence.company.com\/wiki"<\/span>,\n<\/span><\/span>        "CONFLUENCE_USERNAME"<\/span>: "your.email@company.com"<\/span>,\n<\/span><\/span>        "CONFLUENCE_API_TOKEN"<\/span>: "your_api_token"<\/span>\n<\/span><\/span>      }\n<\/span><\/span>    }\n<\/span><\/span>  }\n<\/span><\/span>}\n<\/span><\/span><\/code><\/pre><\/div>
      Remember to run podman-desktop or docker desktop. Because this MCP works as a docker container.<\/p>","title":"Atlassian MCP"},{"content":"Have you ever wondered exactly which files are being hammered by your Linux system in real-time? While tools like iotop or lsof are great, sometimes you want something more visual, custom, and lightweight.\nIn this post, I’ll walk you through how I built a Real-time File I\/O Heatmap using the power of eBPF for data collection and Java 25 for a modern Terminal UI (TUI).\nWhat is eBPF and Why Use It? eBPF (Extended Berkeley Packet Filter) is a revolutionary technology that allows you to run sandboxed programs in the Linux kernel without changing kernel source code or loading kernel modules.\nThink of it as JavaScript for the Kernel. It allows you to:\nObserve: Attach to almost any function in the kernel (kprobes) or userspace (uprobes). Filter: Process data efficiently at the source, inside the kernel. Perform: It’s extremely fast because it avoids expensive context switches between kernel and userspace for every event. For this project, we use eBPF to hook into vfs_read and vfs_write, the gatekeepers of all filesystem activity in Linux.\nIf you want to dive deeper into eBPF, I highly recommend reading Learning eBPF by Liz Rice, it’s an excellent resource.\nThe Architecture Our project consists of three main layers:\nThe eBPF Program (C): Sits in the kernel, intercepts VFS calls, and aggregates stats (reads, writes, bytes) into a BPF Hash Map. The Java Backend (Java 25 + JNA): Uses libbpf via Java Native Access (JNA) to load the BPF program into the kernel and poll the maps. The TUI (Lanterna): A Terminal User Interface that renders the data as a color-coded heatmap. 1. The Kernel Side: eBPF in C We use BPF CO-RE (Compile Once \u2013 Run Everywhere) to ensure our program works across different kernel versions without recompilation.\nSEC("kprobe\/vfs_read") int BPF_KPROBE(vfs_read, struct file *file, char *buf, size_t count) { \/\/ Extract filename from the file struct \/\/ Filter out non-file noise (sockets\/pipes) \/\/ Update the BPF map with bytes read return 0; } The magic happens in file_heatmap.bpf.c, where we traverse the kernel’s dentry structures to reconstruct partial file paths so we can actually see what is being accessed.\n2. The Bridge: JNA and libbpf Interfacing Java with the kernel might sound scary, but libbpf makes it manageable. We defined a JNA interface to map the C functions:\npublic interface LibBpf extends Library { Pointer bpf_object__open(String path); int bpf_object__load(Pointer obj); int bpf_map_lookup_elem(int fd, Pointer key, Pointer value); \/\/ ... } This allows our Java app to behave like a first-class Linux observability tool.\n3. The Frontend: A Terminal Heatmap Using the Lanterna library, we created a TUI that updates every 2 seconds. The heatmap effect is achieved by calculating the “intensity” of I\/O for each file and mapping it to a color gradient from white to red.\nfloat intensity = (float) currentVal \/ maxVal; int green = (int) (255 * (1 - intensity)); int blue = (int) (255 * (1 - intensity)); tg.setBackgroundColor(new TextColor.RGB(255, green, blue)); Challenges Overcome Building this wasn’t without its hurdles:\nSDKMAN & Sudo: BPF requires root privileges, but sudo often strips the environment variables (like JAVA_HOME) set by SDKMAN. I solved this in the Makefile by using absolute paths and passing environment variables explicitly. BPF Verifier: The kernel is very strict. Reconstructing file paths required careful use of bpf_probe_read_kernel_str and bpf_snprintf to keep the verifier happy. vmlinux.h Size: The standard vmlinux.h is over 2MB. I optimized this by using bpftool gen min_core_btf to generate a minified header (~2KB) containing only the types we actually use. Noise Filtering: Initially, the heatmap was flooded with TCP\/UDP socket activity. Adding a filter for S_IFREG (regular files) made the output much cleaner. How to Run It You can find the full source code for this project on GitHub: ozkanpakdil\/java-examples\/ebpf-file-heatmap\nIf you’re on a Linux machine with clang, bpftool, and maven installed, you can try it out:\ngit clone https:\/\/github.com\/ozkanpakdil\/java-examples.git cd java-examples\/ebpf-file-heatmap sudo make run Once it’s running, you can press 1-5 to sort by different metrics (Reads, Writes, Bytes) and watch your system’s I\/O come to life!\nConclusion Combining eBPF’s low-level performance with Java’s high-level productivity (and the latest features in Java 25!) is a powerful way to build Linux tooling. Whether you’re debugging a database or just curious about what your IDE is doing in the background, this heatmap gives you a unique window into your system.\nHappy hacking!\n","permalink":"https:\/\/ozkanpakdil.github.io\/posts\/my_collections\/2026\/2026-01-21-ebpf-java-heatmap\/","summary":"
      Have you ever wondered exactly which files are being hammered by your Linux system in real-time? While tools like iotop<\/code> or lsof<\/code> are great, sometimes you want something more visual, custom, and lightweight.<\/p>\n
      In this post, I’ll walk you through how I built a Real-time File I\/O Heatmap<\/strong> using the power of eBPF<\/strong> for data collection and Java 25<\/strong> for a modern Terminal UI (TUI).<\/p>\n
      What is eBPF and Why Use It?<\/h3>\n
      eBPF (Extended Berkeley Packet Filter) is a revolutionary technology that allows you to run sandboxed programs in the Linux kernel without changing kernel source code or loading kernel modules.<\/p>","title":"Building a Real-time File I\/O Heatmap with eBPF and Java 25"},{"content":"Introduction Today I’m excited to announce the addition of Bun to our microservice framework benchmark suite. The results are nothing short of remarkable . Bun has proven to be one of the fastest runtimes in our entire test suite, competing directly with Rust frameworks!\nWhat is Bun? Bun is a modern JavaScript runtime built from scratch using Zig and JavaScriptCore (the engine that powers Safari). It’s designed to be a drop-in replacement for Node.js with a focus on:\nSpeed - Native code execution and optimized I\/O TypeScript support - First-class TypeScript without transpilation All-in-one toolkit - Runtime, bundler, test runner, and package manager Implementation Details Bun Version: 1.3.5\nThe implementation uses Bun’s native HTTP server API, which is incredibly simple and performant:\nconst port = 8080; const server = Bun.serve({ port: port, fetch(req) { const url = new URL(req.url); if (url.pathname === "\/hello") { const info = { name: "bun", releaseYear: new Date().getFullYear() }; return new Response(JSON.stringify(info), { headers: { "Content-Type": "application\/json" } }); } return new Response("Not Found", { status: 404 }); } }); console.log(`Bun server started on port ${server.port}`); The build process is straightforward . Bun can compile TypeScript directly to a standalone executable:\nbun build --compile .\/main.ts --outfile bun-demo Benchmark Results: The Numbers Speak Here are the complete benchmark results for Bun:\n---- Global Information -------------------------------------------------------- > request count 32000 (OK=32000 KO=0 ) > min response time 0 (OK=0 KO=- ) > max response time 569 (OK=569 KO=- ) > mean response time 157 (OK=157 KO=- ) > std deviation 115 (OK=115 KO=- ) > response time 50th percentile 148 (OK=148 KO=- ) > response time 75th percentile 208 (OK=208 KO=- ) > response time 95th percentile 403 (OK=402 KO=- ) > response time 99th percentile 483 (OK=483 KO=- ) > mean requests\/sec 6400 (OK=6400 KO=- ) Key highlights:\n157ms mean response time : faster than Golang (227ms), .NET 9 AOT (255ms), and all JVM frameworks 6,400 requests\/sec : matching the throughput of Rust frameworks 0 failed requests : 100% success rate under load (unlike Express.js which had 75% failure rate) 569ms max response time : excellent consistency Performance Comparison Let’s put Bun’s performance in perspective with the top performers:\nRank Technology Mean Response Time (ms) Requests\/sec 1 Rust (Warp) 144 6,400 2 Rust (Actix) 154 6,400 3 Rust (Axum) 154 6,400 4 Bun 157 6,400 5 Rust (Rocket) 238 5,333 6 Golang 227 5,333 7 .NET 9 AOT 255 5,333 8 .NET 7 AOT 284 5,333 9 .NET 8 AOT 285 5,333 10 GraalVM Micronaut 339 5,333 Bun vs Express.js: A JavaScript Runtime Showdown The comparison between Bun and Express.js (Node.js) is particularly striking:\nMetric Bun Express.js (Node.js) Mean Response Time 157ms 815ms (3,247ms for OK requests) Requests\/sec 6,400 667 (successful only) Failed Requests 0 24,000 (75% failure rate) Max Response Time 569ms 10,719ms Bun is approximately 5x faster than Express.js in mean response time and handles ~10x more successful requests per second. Most importantly, Bun maintained 100% stability under load while Express.js struggled significantly.\nWhy is Bun So Fast? Several factors contribute to Bun’s impressive performance:\nJavaScriptCore Engine : Safari’s JS engine is highly optimized and often outperforms V8 in certain workloads Zig Implementation : Low-level systems language with minimal overhead Native HTTP Server : Built-in server implementation bypasses the overhead of frameworks like Express Optimized I\/O : Uses io_uring on Linux for efficient async I\/O operations No Transpilation Overhead : Native TypeScript execution Updated Performance Tiers With Bun’s addition, our performance tiers now look like this:\nPerformance Tiers: \ud83e\udd47 TIER 1 (< 200ms): Rust frameworks, Bun - Native compilation or highly optimized runtimes - Minimal overhead, maximum throughput \ud83e\udd48 TIER 2 (200-300ms): Golang, .NET AOT, GraalVM Native - Excellent performance with broader ecosystem \ud83e\udd49 TIER 3 (300-600ms): GraalVM Java frameworks - Native compilation benefits for JVM \ud83c\udfc5 TIER 4 (> 600ms): JVM frameworks, Node.js\/Express.js - Full-featured but with more overhead Conclusion Bun’s benchmark results are genuinely surprising. A JavaScript\/TypeScript runtime competing with Rust frameworks was not something I expected to see. Here are the key takeaways:\nBun is production-ready for high-performance workloads : The 157ms mean response time and 0% failure rate prove it can handle serious traffic.\nJavaScript doesn’t have to be slow : Bun demonstrates that with the right architecture, JavaScript can achieve near-native performance.\nConsider Bun for new projects : If you’re starting a new microservice and your team knows JavaScript\/TypeScript, Bun offers an excellent balance of developer experience and performance.\nThe gap between Bun and Node.js is massive : If you’re currently using Express.js and need better performance, Bun is worth serious consideration.\nFor the complete benchmark results including all frameworks, GraalVM native builds, and detailed statistics, check out the full benchmark report.\nSource code for tests \ud83d\udc48 Rust examples \ud83d\udc48\n","permalink":"https:\/\/ozkanpakdil.github.io\/posts\/my_collections\/2026\/2026-01-10-bun-microservice-framework-benchmark\/","summary":"
      Introduction<\/h2>\n
      Today I’m excited to announce the addition of Bun<\/strong> to our microservice framework benchmark suite<\/a>. The results are nothing short of remarkable . Bun has proven to be one of the fastest runtimes in our entire test suite, competing directly with Rust frameworks!<\/p>\n
      What is Bun?<\/h2>\n
      Bun is a modern JavaScript runtime built from scratch using Zig<\/a> and JavaScriptCore<\/a> (the engine that powers Safari). It’s designed to be a drop-in replacement for Node.js with a focus on:<\/p>","title":"Bun Joins the Microservice Framework Benchmark: Surprisingly Fast JavaScript Runtime"},{"content":"The Spark The other day I came across a fascinating post on Substack by Skilled Coder about Java data structure performance. The post showed some eye-opening numbers for 10M operations:\nGet operations:\nHashMap.get() \u2192 ~140 ms TreeMap.get() \u2192 ~420 ms ArrayList.get(i) \u2192 ~40 ms LinkedList.get(i) \u2192 ~2.5 s Insertion (10M elements):\nArrayList.add() \u2192 ~180 ms HashMap.put() \u2192 ~300 ms LinkedList.add() \u2192 ~900 ms This got me thinking: how do these numbers compare to Eclipse Collections? And more importantly, how can we calculate these numbers ourselves using open source tools?\nWhy Eclipse Collections? Eclipse Collections (EC) has an interesting history. It started around 2004 (probably for Java 1.4) because of buggy and slow implementations in the JDK at the time. Goldman Sachs originally developed it as GS Collections before donating it to the Eclipse Foundation.\nToday, EC provides drop-in replacements for JDK collections with additional functionality and, as we’ll see, slightly better performance.\nThe Benchmark Setup I used JMH (Java Microbenchmark Harness) to run proper benchmarks. You can see the full results on my Java Benchmarks page.\nQuick Comparison Get (avg per operation):\nOperation Time ArrayList.get() ~0.833 ns HashMap.get() ~4.324 ns TreeMap.get() ~272.823 ns LinkedList.get() ~6,036,876.394 ns Insertion (avg per operation):\nOperation Time ArrayList.add() ~133.370 ns HashMap.put() ~378.101 ns TreeMap.put() ~432.432 ns LinkedList.add() ~408.091 ns Detailed Comparison: JDK vs Eclipse Collections Structure Type Insertion (ns\/op) Get (ns\/op) ArrayList JDK ~133.370 ns ~0.833 ns MutableList (FastList) EC ~129.426 ns ~0.831 ns HashMap JDK ~378.101 ns ~4.324 ns MutableMap (UnifiedMap) EC ~371.230 ns ~3.796 ns TreeMap JDK ~432.432 ns ~272.823 ns TreeSortedMap EC ~480.139 ns ~271.022 ns LinkedList JDK ~408.091 ns ~6,036,876.394 ns Key Takeaways 1. Eclipse Collections is slightly faster overall\nFor the most commonly used collections (List and Map), EC shows consistent improvements:\nFastList beats ArrayList by ~3% on insertion and is essentially equal on get UnifiedMap beats HashMap by ~2% on insertion and ~12% on get 2. TreeMap vs TreeSortedMap is a wash\nTreeSortedMap is slightly slower on insertion (~11%) but marginally faster on get. If you need sorted maps, either choice works well.\n3. LinkedList is still terrible for random access\nLook at that LinkedList.get() number: ~6 million nanoseconds per operation! This is because LinkedList has O(n) complexity for random access \u2014 it must traverse the list from the beginning (or end) to find each element.\nAs Skilled Coder wisely noted: “Once you know this, you stop misusing LinkedList forever.”\nWhy These Performance Differences? Understanding the “why” helps you make better choices:\nArrayList\/FastList = contiguous memory, cache-friendly. The CPU can prefetch data efficiently. HashMap\/UnifiedMap = hashing + pointer chasing. UnifiedMap uses a more compact memory layout. TreeMap\/TreeSortedMap = O(log n) + rebalancing. Red-black tree operations. LinkedList = worst cache locality + pointer traversal. Every access is a cache miss. When to Use Eclipse Collections Consider EC when:\nYou’re doing heavy collection operations and every nanosecond counts You want additional APIs like select(), reject(), collect(), groupBy() You need primitive collections (avoiding boxing overhead) You want immutable collections with a rich API Running Your Own Benchmarks Want to reproduce these results? Check out the JMH documentation and my benchmark code at java-benchmarks.\nWrap-up This was a fun research project! The numbers confirm what the Eclipse Collections team has been saying for years: their implementations are well-optimized and can provide meaningful performance improvements over JDK collections.\nFor most applications, the difference won’t be noticeable. But if you’re building high-performance systems or processing large datasets, EC is worth considering.\nI shared these findings on my Substack \u2014 feel free to check it out and share your own benchmark experiences!\nReferences Eclipse Collections Eclipse Collections History JMH - Java Microbenchmark Harness My Java Benchmarks Page Skilled Coder’s Original Post ","permalink":"https:\/\/ozkanpakdil.github.io\/posts\/my_collections\/2025\/eclipse-collections-vs-jdk-collections\/","summary":"
      The Spark<\/h3>\n
      The other day I came across a fascinating post on Substack by Skilled Coder<\/a> about Java data structure performance. The post showed some eye-opening numbers for 10M operations:<\/p>\n
      Get operations:<\/strong><\/p>\n