of the worst case for examplethe most efficient algorithm on average might have particularly bad worst case efficiency we will see particular examples of this when we consider efficient algorithms for sorting and searching concrete measures for performance these dayswe are mostly interested in time complexity for thiswe first have to decide how to measure it something one might try to do is to just implement the algorithm and run itand see how long it takes to runbut that approach has number of problems for oneif it is big application and there are several potential algorithmsthey would all have to be programmed first before they can be compared so considerable amount of time would be wasted on writing programs which will not get used in the final product alsothe machine on which the program is runor even the compiler usedmight influence the running time you would also have to make sure that the data with which you tested your program is typical for the application it is created for againparticularly with big applicationsthis is not really feasible this empirical method has another disadvantageit will not tell you anything useful about the next time you are considering similar problem therefore complexity is usually best measured in different way firstin order to not be bound to particular programming language or machine architectureit is better to measure the efficiency of the algorithm rather than that of its implementation for this to be possiblehoweverthe algorithm has to be described in way which very much looks like the program to be implementedwhich is why algorithms are usually best expressed in form of pseudocode that comes close to the implementation language what we need to do to determine the time complexity of an algorithm is count the number of times each operation will occurwhich will usually depend on the size of the problem the size of problem is typically expressed as an integerand that is typically the number of items that are manipulated for examplewhen describing search algorithmit is the number of items amongst which we are searchingand when describing sorting algorithmit is the number of items to be sorted so the complexity of an algorithm will be given by function which maps the number of items to the (usually approximatenumber of time steps the algorithm will take when performed on that many items in the early days of computersthe various operations were each counted in proportion to their particular 'time cost'and added upwith multiplication of integers typically considered much more expensive than their addition in today' worldwhere computers have become much fasterand often have dedicated floating-point hardwarethe differences in time costs have become less important howeverwe still we need to be careful when deciding to consider all operations as being equally costly applying some functionfor examplecan take much longer than simply adding two numbersand swaps generally take many times longer than comparisons just counting the most costly operations is often good strategy big- notation for complexity class very oftenwe are not interested in the actual function (nthat describes the time complexity of an algorithm in terms of the problem size nbut just its complexity class this ignores any constant overheads and small constant factorsand just tells us about the principal growth