Cache procesora w pigułce: dlaczego kolejność ma znaczenie

Procesor jest dziś dużo szybszy niż pamięć, z której czyta. Na tyle szybszy, że pobranie liczby z RAM-u trwa mniej więcej tyle, co dwieście zwykłych działań. Żeby nie stać bezczynnie, procesor trzyma pod ręką małą, bardzo szybką pamięć podręczną — cache.

Analogia z biurkiem

Wyobraź sobie, że piszesz pracę. Kartka przed tobą to rejestry procesora. Blat biurka to cache. Regał w pokoju to RAM. Biblioteka na drugim końcu miasta to dysk.

Wszystko, co masz na biurku, jest natychmiast dostępne. Po coś z regału trzeba wstać. Po coś z biblioteki — wyjść z domu. Dobrze napisany program to taki, który układa sobie robotę tak, żeby jak najrzadziej wstawać od biurka.

Procesor nigdy nie bierze jednej rzeczy

Kiedy procesor musi sięgnąć do pamięci, nie pobiera pojedynczej liczby. Pobiera cały blok, zwykle 64 bajty — tak zwaną linię cache. Prosząc o jedną liczbę, dostajesz w gratisie kilkanaście sąsiednich.

Dlatego program, który czyta dane po kolei, jest szybki: co szesnasty odczyt naprawdę idzie do pamięci, resztę procesor ma już u siebie. Program, który skacze po pamięci losowo, za każdym razem czeka od nowa. Ta sama liczba operacji, a różnica w czasie potrafi być pięciokrotna.

Wolny kod zwykle nie liczy za dużo. On po prostu za często czeka na dane.

To samo, tylko na stronie internetowej

Programista webowy nie żongluje liniami cache, ale zasada działa identycznie — tylko piętro wyżej:

• Sto zapytań zamiast jednego. Pętla, która dla każdego rekordu odpytuje bazę osobno, to dokładnie ten sam błąd co skakanie po pamięci. Jedno zapytanie z JOIN bywa szybsze sto razy.
• SELECT * na dużej tabeli. Ciągniesz przez sieć megabajty, żeby wyświetlić tytuł i datę. Wypisz kolumny, których naprawdę potrzebujesz.
• Brak indeksu. Bez indeksu baza czyta całą tabelę, żeby znaleźć jeden wiersz. To wyprawa do biblioteki po każdą książkę.
• Cache aplikacji. Redis obok aplikacji jest dla bazy tym, czym cache dla RAM-u. Ta sama idea, inna skala.

Jeden praktyczny wniosek

Zanim zaczniesz przepisywać kod na sprytniejszy, sprawdź, ile razy i skąd sięga po dane. Zwykle to właśnie tam siedzi problem — i zwykle poprawka zajmuje godzinę, a nie tydzień.

I zasada, która nie zmienia się od dekad: najpierw zmierz, potem optymalizuj. Intuicja co do tego, gdzie program traci czas, myli się częściej niż rzut monetą.