<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Gc on dplabs — Software Engineering &amp; Technology Consultancy</title>
		<link>https://dplabs.tech/tags/gc/</link>
		<description>Recent content in Gc on dplabs — Software Engineering &amp; Technology Consultancy</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Mon, 23 Jun 2025 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://dplabs.tech/tags/gc/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Java Performance: Stop Guessing, Start Measuring</title>
				<link>https://dplabs.tech/blog/java-performance-stop-guessing/</link>
				<pubDate>Mon, 23 Jun 2025 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/java-performance-stop-guessing/</guid>
				<description>&lt;p&gt;Most Java performance work starts in the wrong place. An engineer identifies &amp;ldquo;the application is slow,&amp;rdquo; forms a hypothesis based on code familiarity, and makes changes based on intuition. Sometimes it works. More often, the actual bottleneck was elsewhere and the optimized code is now more complex with no performance benefit.&lt;/p&gt;&#xA;&lt;p&gt;The methodology matters: &lt;strong&gt;measure, identify the bottleneck, optimize, measure again&lt;/strong&gt;. In that order. Not &amp;ldquo;optimize the thing that looks suspicious, then measure.&amp;rdquo;&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
