Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

'Thin Patterns' for Killing Design Pattern Bloat?

DZone's Guide to

'Thin Patterns' for Killing Design Pattern Bloat?

· Performance Zone ·
Free Resource

SignalFx is the only real-time cloud monitoring platform for infrastructure, microservices, and applications. The platform collects metrics and traces across every component in your cloud environment, replacing traditional point tools with a single integrated solution that works across the stack.

This week I read a 2010 FoSER paper on software bloat analysis. The paper summarizes a bunch of research on runtime bloat of Java applications, nicely Java-flavoring Myhrvold's Four Laws and putting solid research behind those ubiquitous war-stories. Also includes a good bibliography.

The whole text is worth reading (only 4pp), but one direction for further research -- which the authors call 'thin patterns' -- stuck out in my mind:

While design patterns have been extremely  successful in helping programmers write highly-manageable code,  they are the root causes of many types of runtime bloat.  In many large applications, for instance, in order to implement a visitor pattern, the programmer uses inner classes to represent different kinds of visitors, which contain nothing but a visit method. Such a visitor class can be instantiated an extremely large number of times (e.g., the allocation sites are located in loops with many layers of nesting), and all objects created are identical: they have no data and are used only for dynamic dispatch. It is not free to create and deallocate these objects, and significant overhead reduction can be seen when we use only the method without creating objects.


Future research on patterns may consider the creation of a few specialized versions for each existing pattern (i.e., thin patterns), which provides different tradeoffs between inefficiency and modularity. On the compiler side, pattern-aware optimization techniques could be expected to remove inefficiencies and generate higher-quality code.

This sounded exciting, so I did a quick lit search and couldn't find any follow-up. So I emailed one of the authors, who replied (super-amazingly-quickly) and confirmed that he also doesn't know of any more recent research in this direction.

But plenty of experienced Java devs have thought long and hard about the performance effects of using design patterns. You know better than most how to write performant Java and not reinvent the wheel at the same time.

So here's a hopefully-fruitful query:

Have you run into significant bloat caused by sloppy use of design patterns? If so, have you developed more specialized patterns optimized for your applications?

And if so (and here's the fruitfullest part) have you found any of these specialized patterns useful in other applications, or are the optimizations too application-specific to be applied repeatedly?

SignalFx is built on a massively scalable streaming architecture that applies advanced predictive analytics for real-time problem detection. With its NoSample™ distributed tracing capabilities, SignalFx reliably monitors all transactions across microservices, accurately identifying all anomalies. And through data-science-powered directed troubleshooting SignalFx guides the operator to find the root cause of issues in seconds.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}