api - Should changing the documented performance of a method be considered a breaking change? -


it seems common rule in software development once have deployed public api, especially if you've documented api (which—yeah, should have), must think long , hard before making changes break backwards compatibility api such changes breaking changes. in fact i'm sure many developers argue flat-out should not @ all, regardless of how long , hard may think it.

occasionally developer document performance of method. lot of msdn docs this, example, using big o notation. changing also constitute "breaking" change? maybe that's not clear question; put way: should avoided?

it seems me in cases where, e.g., might have developed superior algorithm solve problem, if had documented algorithm o(n2) might forgiven improving api replacing superior algorithm is, say, o(log n). users of api might notice , would, imagine, feel glad improvement.

on other hand wonder whether ever considered "excusable" worsen performance of component of api other reasons—e.g., optimize common use case results in worse performance in general case; optimize memory on cpu cycles or vice versa; eliminate external dependency had caused other issues, etc.

my intuition tells me improving performance ok. opposite? ok, assuming update documentation? wrong? i'm looking reasonable guidelines, here.

well, if make performance better doubt you'll complaints.

otherwise, i'd depends. if have access source code clients, upright thing through them , verify change won't cause them trouble.

if more complicated that, , liable make use-case's performance worse, should go talk clients , warn them of change.

if can't either (eg: shrink-wrapped api of kind), yeah, best implement change alternative call or something, , leave old call alone.


Comments

Popular posts from this blog

java - SNMP4J General Variable Binding Error -

windows - Python Service Installation - "Could not find PythonClass entry" -

Determine if a XmlNode is empty or null in C#? -