Egy megjegyzés, ami e problémánál lehet, hogy releváns, lehet, hogy nem.
Amikor ilyeneket írtál, hogy "de tény: ha a python is soronként olvassa az inputot, akkor minimálisra csökken az előnye a többiekkel szemben.", akkor eszembe jutott egy saját benchmark tapasztalatom.
Pár éve nagyon optimalizálnom kellett egy kódot, ami számdarálást végzett sok megabájtos tömbökön. A részletek itt nem fontosak, hisz a probléma jellege igen eltért, de a tanulság talán itt is releváns: Az olyan programok futásideje, amelyek a CPU cache méreténél sokkal nagyobb adatokon dolgoznak és egy-egy kiolvasott adattal kevés műveletet végeznek borzalmasan függ a CPU cache viselkedésétől, az adatok memóriában való elhelyezkedésétől és a program memória írás/olvasás műveleteinek sebességétől.
No, az persze nyilván mindenkinek triviális, hogy ha pl. soronként olvasok egy fájl be és minden beolvasás eredményét egy új malloc()-cal (nem C-ben mással) foglalt területre teszem le, ezekből listát csinálok, akkor egy jó fragmentálódott memóriát kell kezelnem, míg ha egyszerre egy nagy helyet foglalok a teljes fájltartalomnak és oda öntök mindent, akkor nem lesz fragmentálva a program által lefoglalt terület a RAM-ban. A fent idézett különbség a Python soronkénti/egybe beolvasása esetek között akár ebből is fakadhat. Nem tudom igazán, mert a Python lelki világát nem ismerem, de a jelenség nagyon ismerősen hangzott. Első pillanatban nem látszik, miért baj, ha a kezelt adattömb szét van forgácsolva a RAM-címeken, de ha a CPU szintjén nézzük, akkor érthető, miért kerül több időbe, ha hirtelen nagyon távoli területet kell beolvasni, aztán visszaugrani ide, stb.
Számtömbökkel végzett optimalizálási tapasztalataim szerint (ha cache-nél sokkal nagyobb adattömeg, olvasás után kevés, egyszerű művelet a sok adattal, ...) elvileg egyenértékű kódok is jelentős futásidő-különbséget adnak még egybefüggő memória-foglalás esetén is, ha az adott CPU-n az egyik algoritmus sok cache-miss-t generál. Ezeket az adott CPU igen mély ismerete nélkül előre látni nem lehet, így a szegény felhasználó/programozó előtt csak szerencse kérdésének tűnik, hogy egy adott implementáció egy adott CPU-n miért gyorsabb, mint a másik, holott akár assembly szinten is számolva azonos számú művelettel jutnak el az eredményig.
Na, ez így elég kusza lett, de ennek nagyrészt a helyhiány az oka, valójában jól utánajártam az ügynek. (pl. a pontosság kedvéért a Linux scheduler-je alól kivettem azokat a processzormagokat, melyeken benchmarkoltam, és ezeken csak a benchmark futott.)
Ami a sok dumám konklúziója: szerintem érdekes lenne megismételni a mérést egy teljesen más cache-architektúrájú rendszeren, no meg persze nemcsak Virtualboxban. Azt sejtem, hogy a végső, optimalizált változataid közti erőviszonyok ettől is függenek. Ha ez igaznak bizonyulna, akkor nem algoritmikus különbségek, a regex-motorok eltérései, stb. határozzák meg a vizsgált problémát teljesen, hanem a CPU-cache-RAM rendszer részletei is.