Esta página ainda não foi traduzida, por isso é exibida em inglês. Ajude a traduzir

Dart vs FxDart › #1 · Top 3 largest expenses

Top 3 largest expenses

Toss-up

• sortBy
• take

Requirement

From a month of expenses, print the three largest — merchant and amount, biggest first. The data is in the code below; both versions must print the lines shown under Expected output.

Airline Ticket  $289.99
New Headphones  $129.00
Electric Co     $60.34

Side by side

Why they differ

They barely do — this one is a tie on the page. Both sides sort on a negated key to get descending order and take the first three; package:collection's sortedBy is every bit as direct as FxDart's sortBy (core List.sort alone would mutate in place and need an explicit comparator, but collection is a standard dependency). The only real difference in the listing is where the vocabulary lives: an extension method from a package vs a step in a chain that also offers scan, chunk, and async variants. Pick either with a clear conscience.

The listing is a tie; the clock is not. At a million rows the bars below have FxDart about 2.6× faster (200 ms vs 521 ms), and that is not a smarter big-O — both copy the list and run a stable O(n log n) merge sort. The difference is what one comparison costs.

Native sortedBy is collection's mergeSortBy: it sorts the rows and calls the key extractor inside every comparison. A million rows is about twenty million calls to (t) => -t.amount. The key type is a generic K extends Comparable — here num — so each of those keys is a heap-allocated boxed double compared through a virtual compareTo.

FxDart's sortBy extracts first. One walk of the list writes every key into a Float64List (it noticed they were all double). Then it merges the keys and the rows together, sequentially: each comparison is two machine doubles from a typed array, using a VM compare on this data (the amounts are ordinary finite positives, so there is no NaN or -0.0 to force the slower compareTo path). One extraction per row, no boxing, no dispatch, and no random index chase. An earlier sortBy did decorate by sorting a list of indices with List.sort; that is gone. The merge is stable by construction — equal keys keep their input order on both sides now.

The honest limit: when the keys are not uniformly double, int, or String, sortBy falls back to a generic comparator and the advantage disappears. Memory at a million rows is close (about 123 MB vs 130 MB) — both keep the row copy plus a scratch buffer. The amounts here are all distinct, so stability does not show on the printed three lines.