Browse Prior Art Database

Hysteresis Performance Switch

IP.com Disclosure Number: IPCOM000032467D
Original Publication Date: 2004-Nov-05
Included in the Prior Art Database: 2004-Nov-05
Document File: 1 page(s) / 37K

Publishing Venue

IBM

Abstract

Hyseresis Patttern For Performance Decisions

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 69% of the total text.

Page 1 of 1

Hysteresis Performance Switch

Often applications tailor their performance to optimise for the most common case. "Make the common case fast". While this is reasonable, it is hardly ideal.

    For example, suppose a messaging platform is optimised for the case when a queue is empty, which may be true most of the time.

    For the situations when the queue is not empty but is nearly full, say under load, then these optimizations might actually hinder performance.

    One needs some way to make different optimisation decisions, depending on the situation.

    However, there is a problem. It may be that the overhead of changing ones optimisation strategy is prohibitive. For example if, in the case when the queue is nearly full, a more appropriate optimisation strategy is chosen that, unfortunately, requires the creation of some objects, then one only wants to take the decision to change strategy if it is known that it is going to "pay off" - in other words there is needed some way of making a valid guess as to whether the performance improvement of the optimisation outweighs the cost of changing strategy.

    A single module is provided that can make sophisticated performance decisions, which can interrogated by other modules in the code. The core advantages are that it enables the code to tailor optimisations for given situations, can make accurate decisions on when to change optimisation strategy

    The switch can be in one of several know states. For each state, a different section of th...