IMDb Algo Bench
What a sort really costs, on 40,000 films.
- Type
- Algorithms
- Context
- University project, BUT year 1
- Year
- 2024
- Technologies
- Java, JConsole
A Java console application loads an IMDb film database, from 100 to 40,000 rows, then lets you display, sort, filter, search and delete them. Every operation is timed, to compare selection sort, merge sort, Java’s own sort, linear search and binary search in practice.
The measurements mostly revealed the effect of the data structure. On a LinkedList, merge sort goes from 4 seconds to 124 seconds when the number of films is multiplied by four: every access by position walks the list again. Collections.sort, which copies the list into an array before sorting, stays under 20 milliseconds.
I completed the analysis with JConsole: loading 40,000 films takes about 110 MB, and simply displaying them pushes the heap to almost 600 MB, because of the strings created and thrown away for every row.
- Selection sort, merge sort and Collections.sort timed
- Linear and binary search compared
- Memory and CPU tracked with JConsole

JConsole while the data loads: about 110 MB of memory

While the films are displayed, memory climbs to almost 600 MB

Selection sort on 1,000 films: memory barely moves, the whole cost is time