Liksom tidigare konstaterat rörande CPU-schedulering (ordentligt mycket mer CPU-kraft realiserat för mig från algoritmen: Ta allt som finns, fatta inga egna beslut om att vänta på något och låt Hans oroa sig för på ev. problem som kan uppstå om till blir brist och dator blir tyst: Bara gör på) kan Linux (åtminstone den Ubuntu variant - variant i mening av att jag förändrat den en hel del över åren - jag kör) kan prestandan förbättras genom att förändra koden. Utplattning ger viss förbättring på ganska liten insats och mer kan vara möjligt. Förbättring konstaderad optimering rör filkopieringen medan referensen i titel rörande ram-minne avser vad jag läste om Linux stacken och som fick mig att titta och pröva lite medan koden på vad mer intressant för mig (att accesstid ram-minne eller liknande är hastighetsbestämmande för mig finns inte).
Nedsidan är här i alla fall som aktuellt gjort av mig (användande kodoptimerings-arbete som jag kan) att man får ännu värre kod att underhålla än innan. Så egentligen är jag inte 100% på att så divergerat projekt som Linux så centralt ändå i arkitekturen bör arbete annorlunda än de gör rörande sådant här.
Möjligheten kom till mig i samband med att jag sista gången sökte information om olika möjligheter att introducera närmare "ram-diskar" och "minnesbussar" för snabb överföring av data mellan olika komponenter och en presentation rörande en ny typ (ny för mig som har ganska atavistisk begreppsbild rörande vad ran-minnen kallas för sist uppdaterad kanske 1995 eller så) och strategi för att dra nytta av dem i Linux kernel och såväl komplexiteten som att noterade att man i andra delar av jämförbar access hade problem att få nytta av snabbare hårdvara därför att stacken bottnade ut.
Men alltså även kopiering mellan hårddiskar när det handlar om väldigt många små filer går att få lite med kodförbättring. Trots viss positiv effekt på ganska liten insats lär jag inte fortsätta det. Jag varken gillar C eller den C-kod som man har efter att suttit och försökt över-optimera den. Det är kod av typen att behöver man göra om optimering så är risken hög att man sparar tid på att utgå från den o-optimerade koden ännu en gång snarare än att ändra resultatet av befintlig insats: Dyrt arbete över tiden med andra ord.
Att förhållandevis stora möjligheter till optimering i Linux finns att hämta fram är dock bra att veta. Konstaterat i detta område förutom närmare hantering CPU:er gör det troligt att möjligheten finns allmänt i områden som lätt prestanda-flaskhalsar (så här spontant kom jag faktiskt inte att tänka på något mer än just att utnyttja alla CPU:er hårt samt kopiera filer snabbt: Det är mina två begränsande faktorer medan säkert andra områden ganska diffusa för mig är aktuella för annan användning som områden inom grafik m.m.).
