AR
FR

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

View the code on GitHub

sort time (ms, log scale) - on a LinkedList0,11101001 k10 k100 k1000 k1001 00010 00040 000filmsselection sorttoo longmerge sort124 sCollections.sort18 ms
JConsole while the data loads: about 110 MB of memory

JConsole while the data loads: about 110 MB of memory

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

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

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

Next projectAntCloud