Searching Algorithms
Data Structures
Algorithm Efficiency
Binary Search
Linear Search

Efficient way to search an element

Data Structures & Algorithms practice on Codemia

Step through 300 algorithm problems with animated visualisers that show the data structure changing as the code runs.

Practice algorithms

Introduction

There is no single "most efficient" search method for every program. The right answer depends on how the data is stored, whether it is sorted, how often it changes, and whether you need exact lookup or range-style queries.

Start with the Data Structure

The search algorithm is usually chosen by the container, not by the lookup alone. If the data is in an unsorted list, you cannot do better than checking items one by one unless you first build another structure around it.

For example, a linear search over an array is simple and sometimes perfectly acceptable:

python
1def linear_search(values, target):
2    for index, value in enumerate(values):
3        if value == target:
4            return index
5    return -1
6
7
8numbers = [8, 3, 11, 2, 7]
9print(linear_search(numbers, 11))

This runs in O(n) time. That sounds slow, but for a small list or a one-time lookup, it is often the most practical solution because it has no setup cost.

Use Binary Search on Sorted Data

If the data is sorted and you only need lookup by value, binary search is a much better choice. Instead of scanning everything, it repeatedly cuts the search interval in half.

python
1def binary_search(values, target):
2    left = 0
3    right = len(values) - 1
4
5    while left <= right:
6        mid = (left + right) // 2
7
8        if values[mid] == target:
9            return mid
10        if values[mid] < target:
11            left = mid + 1
12        else:
13            right = mid - 1
14
15    return -1
16
17
18numbers = [2, 4, 7, 9, 13, 18, 21]
19print(binary_search(numbers, 13))

Binary search runs in O(log n) time, which is much faster for large inputs. The tradeoff is that the data must already be sorted, and keeping it sorted may cost time when you insert new elements.

If your main operation is "Does this value exist" or "Give me the value for this key," a hash table is usually the fastest general-purpose option. In Python that means set or dict. In Java it means HashSet or HashMap.

python
1users = {"alice", "bob", "carol"}
2
3print("alice" in users)
4print("dave" in users)

Average lookup is close to O(1), which is why hash-based structures are so common. The downside is that they do not preserve sorted order in the same way a sorted array or tree does, so they are not ideal when you need smallest, largest, or next-greater queries.

Trees Help When Order Matters

Balanced search trees sit between arrays and hash tables. They are slower than a hash table for exact lookup, but they keep elements ordered and still give efficient search, insertion, and deletion.

That makes trees useful for:

  • range queries
  • nearest-value lookup
  • iteration in sorted order
  • workloads with frequent inserts and deletes

In practice, many standard libraries hide the tree implementation behind sorted-map and sorted-set abstractions.

The Real Decision Rule

A good rule of thumb looks like this:

  • use linear search for tiny or one-off unsorted data
  • use binary search for sorted arrays
  • use a hash table for fast exact membership tests
  • use a balanced tree when order-sensitive queries matter

The efficiency of searching is often determined before the search begins. If your application performs a million lookups, it is usually worth organizing the data for those lookups up front.

Here is a simple example that converts a list into a set to make repeated searches fast:

python
1items = ["red", "blue", "green", "yellow"]
2item_set = set(items)
3
4queries = ["red", "purple", "yellow"]
5for query in queries:
6    print(query, query in item_set)

Building the set costs time once, but every later membership test is cheap.

Complexity Is Not the Only Cost

Big-O notation matters, but constants and memory use matter too. A hash table may be asymptotically faster than binary search, but it also uses extra memory. A sorted list may be fine if the data is small and cache-friendly. An index may improve read speed while making writes slower.

That is why performance questions should always include workload details:

  • how large is the dataset
  • how often does it change
  • how many searches happen per write
  • do you need order or just existence

Without those details, "efficient" is too vague.

Common Pitfalls

The most common mistake is choosing binary search on data that is not sorted. The code may compile and run, but the answers will be wrong.

Another mistake is rebuilding an expensive search structure for every lookup. For example, converting a list into a set inside a loop destroys the performance benefit.

Developers also overfocus on asymptotic complexity and ignore real constraints. A linear scan over ten items is often better than maintaining a more complex structure.

Finally, do not assume exact lookup and ordered lookup are the same problem. Hash tables are excellent for the first and poor for the second.

Summary

  • The best search method depends on how the data is stored and queried.
  • Linear search is simple and good enough for small unsorted data.
  • Binary search is efficient for sorted arrays and runs in O(log n).
  • Hash tables are usually best for repeated exact lookups.
  • Trees are useful when you need both searching and sorted-order operations.

Related reading
Course
Intermediate
27 lessons
15 hours
DSA Fundamentals

Master algorithmic patterns and data structures through hands-on LeetCode-style problems - from arrays and hashing to dynamic programming and advanced graphs.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

Data Structures & Algorithms practice on Codemia

Step through 300 algorithm problems with animated visualisers that show the data structure changing as the code runs.

Practice algorithms

All Rights Reserved.