Microsoft once used its own brand of ‘Lego’ to optimize Windows

In a nostalgic reflection on the evolution of software performance, former Microsoft engineer Dave Plummer shared insights from his time at the company during the ’90s. He recalled the challenges of developing software on machines with a mere 12 MB of RAM, a stark contrast to today’s computing power. Despite the limitations, the software of that era was often perceived as more responsive and efficient, prompting curiosity about the methods employed to achieve such performance.

At the heart of Microsoft’s strategy was an internal tool known as Basic Block Tool (BBT), affectionately dubbed Microsoft Lego. This innovative application allowed engineers to optimize software binaries by reorganizing their internal structures, effectively enhancing execution speed. Plummer explained that while a typical binary might contain around 10 MB of code, only a fraction—approximately 300 KB—was necessary for startup. However, if that essential code was scattered throughout the larger binary, it forced the loader and memory manager to access far more pages than needed, leading to significant performance degradation.

“If a trip to disk was needed to page the code in and out, the performance impact could be disastrous,” Plummer noted. BBT addressed this issue by effectively defragmenting binaries, grouping related code together to streamline access and execution. This practice not only improved performance but also made a tangible difference in user experience, particularly for large products like Windows and Office, which were designed to run on constrained hardware.

As computational power has increased, the principles behind BBT have continued to influence software optimization techniques. Modern tools like BOLT enhance application performance by optimizing binary layouts, while HP’s Dynamo takes it a step further by optimizing code at runtime. However, Plummer cautioned that manipulating binaries carries inherent risks, and such endeavors require a meticulous approach.

“Windows and Office were large native code products running on constrained machines, and the wins were user-visible,” he explained. Reducing the number of memory pages accessed during boot or application startup could significantly enhance multitasking capabilities. “If you could keep hot code out of the swap file, the whole system felt less like it was dragging a refrigerator through wet cement.”

Reflecting on the current state of software development, Plummer expressed concern over whether the same focus on performance persists today. He pointed out that modern software faces similar challenges, albeit on a larger scale. “The binaries are much larger. The services are distributed. The frameworks are deeper. The machines are faster, but the dependency graphs are absurd,” he remarked.

Despite advancements, Plummer emphasized that the fundamental principle of locality remains crucial. “Put the hot data together. Put the hot code together. Keep the common path small. Push rare paths away,” he advised. “Don’t make the CPU fetch a haystack when it only needs the needle.”

MORE CONTEXT

As the tech landscape continues to evolve, the lessons from the past serve as a reminder of the importance of efficient software design. The quest for performance optimization remains relevant, urging developers to consider how they can apply these timeless principles to meet the demands of modern computing environments.

Winsage
Microsoft once used its own brand of 'Lego' to optimize Windows