Vägen till typkontroll av 4 miljoner rader Python-kod. Del 2

Idag publicerar vi den andra delen av översättningen av materialet om hur Dropbox organiserade typkontroll för flera miljoner rader Python-kod.

→ Läs första delen

Officiellt stöd för typer (PEP 484)

Vi genomförde våra första seriösa experiment med mypy på Dropbox under Hack Week 2014. Hack Week är ett evenemang som hålls av Dropbox under en vecka. Under denna tid kan anställda arbeta med vad de vill! Några av de mest kända tekniska projekten från Dropbox har startats just under sådana evenemang. Som ett resultat av detta experiment drog vi slutsatsen att mypy ser lovande ut, även om projektet ännu inte var redo för bred användning.

Vid den tiden flöt idén om att standardisera system för typinmatningar i Python i luften. Som jag redan nämnt, sedan Python 3.0 har det varit möjligt att använda typanoteringar för funktioner, men dessa var bara godtyckliga uttryck utan specifik syntaktik och semantik. Under programkörningen ignorerades dessa anoteringar i stor utsträckning. Efter Hack Week började vi arbeta med standardiseringen av semantiken. Detta arbete ledde till skapandet av PEP 484 (detta dokument utarbetades gemensamt av Guido van Rossum, Łukasz Langa och mig).

Våra motiv kan ses från två perspektiv. För det första hoppades vi att hela Python-ekosystemet skulle kunna anta en gemensam metod för användning av typinmatningar (type hints — en term som används i Python som en analog till 'typannoteringar'). Detta, med alla eventuella risker i åtanke, skulle vara bättre än att använda många ömsesidigt oförenliga metoder. För det andra ville vi öppet diskutera mekanismerna för typanotering med många representanter från Python-communityn. Delvis berodde denna önskan på att vi inte ville framstå som 'avvikare' från språkets grundläggande idéer i ögonen på den breda massan av Python-programmerare. Det är ett dynamiskt typat språk, känt för 'anktypning'. I communityn, i början, kunde man inte undvika en viss misstänksamhet mot idén om statisk typning. Men denna inställning har så småningom minskat — efter att det blev klart att statisk typning inte planeras att göras obligatorisk (och efter att folk insåg att det faktiskt är användbart).

Den antagna syntaktiska strukturen för typanvisningar liknade mycket den som mypy då stödde. Dokumentet PEP 484 släpptes tillsammans med Python 3.5 år 2015. Python var inte längre ett språk som enbart stödde dynamisk typning. Jag gillar att tänka på detta som en viktig milstolpe i Pythons historia.

Början av migrationen

I slutet av 2015 bildades ett team av tre personer på Dropbox för att arbeta med mypy. Det bestod av Guido van Rossum, Greg Price och David Fisher. Från och med detta började situationen utvecklas mycket snabbt. Det första hinder som mypy stötte på var prestanda. Som jag nämnt tidigare funderade jag i projektets tidiga skeden på att översätta mypy:s implementation till C, men den idén ströks för tillfället. Vi blev fast vid att vi använde CPython-tolkaren, som inte hade en hastighet tillräcklig för verktyg som mypy. (Projektet PyPy, en alternativ implementation av Python med JIT-kompilator, hjälpte oss inte heller.)

Som tur var fick vi hjälp av vissa algoritmiska förbättringar. Den första kraftfulla "acceleratorn" var implementeringen av inkrementell kontroll. Idén bakom denna förbättring var enkel: om alla beroenden för en modul inte hade förändrats sedan mypy senast kördes, så kunde vi använda de data som cacheats under föregående session vid arbetet med beroenden. Vi behövde bara utföra typkontroll i de ändrade filerna och i filer som berodde på dem. Mypy gick till och med ett steg längre: om modulen yttre gränssnitt inte hade förändrats, ansåg mypy att andra moduler som importerade denna modul inte behövde kontrolleras igen.

Den inkrementella kontrollen har verkligen hjälpt oss när vi har använt oss av annoteringar på stora mängder befintlig kod. Problemet är att denna process vanligtvis involverar många iterativa körningar av mypy, eftersom annotationerna gradvis läggs till i koden och förbättras över tid. Den första körningen av mypy var fortfarande väldigt långsam, eftersom den behövde kontrollera många beroenden. För att förbättra situationen implementerade vi en mekanism för fjärr-cache. Om mypy upptäcker att den lokala cachen sannolikt är föråldrad, laddar den ner den aktuella cachen för hela kodbasen från ett centraliserat repository. Därefter utförs den inkrementella kontrollen med hjälp av denna snapshot. Detta har avancerat oss ytterligare ett steg mot att öka mypy:s prestanda.

Det var en period av snabb och naturlig implementering av typkontrollsystemet på Dropbox. I slutet av 2016 hade vi redan omkring 420 000 rader Python-kod med typannoteringar. Många användare tog entusiastiskt till sig typkontrollen. På Dropbox användes mypy av allt fler utvecklingsteam.

Allt såg bra ut då, men vi hade fortfarande mycket kvar att göra. Vi började genomföra regelbundna interna användarundersökningar för att identifiera problemområden i projektet och förstå vilka frågor som behövde lösas först (denna praktik används fortfarande i företaget idag). Det blev klart att två uppgifter var de viktigaste. För det första behövde vi mer kodtäcke med typer, och för det andra behövde mypy att arbeta snabbare. Det var helt tydligt att vårt arbete med att snabba upp mypy och implementera det i företagets projekt fortfarande hade en lång väg kvar att gå. Med full insikt om vikten av dessa två uppgifter satte vi igång med att lösa dem.

Mer prestanda!

Inkrementella kontroller har påskyndat mypy, men verktyget är fortfarande inte tillräckligt snabbt. Många inkrementella kontroller tog runt en minut. Orsaken till detta var cykliska importer. Detta förvånar förmodligen ingen som har arbetat med stora kodbaser skrivna i Python. Vi hade uppsättningar med hundratals moduler, där var och en indirekt importerade alla andra. Om någon fil i importcykeln ändrades, tvingades mypy att bearbeta alla filer som ingick i denna cykel, och ofta även moduler som importerade moduler från denna cykel. En av dessa cykler var den ökända "beroendeknuten" som orsakade många problem i Dropbox. Vid ett tillfälle innehöll denna struktur flera hundra moduler, och den importerades, direkt eller indirekt, av många tester, samt användes i produktionskoden.

Vi övervägde möjligheten att "reda ut" cykliska beroenden, men vi hade inte resurserna för att göra det. Det fanns alldeles för mycket kod som vi inte kände till. Till slut landade vi på ett alternativt tillvägagångssätt. Vi bestämde oss för att få mypy att fungera snabbt även med "beroendeknutar". Vi nådde detta mål med hjälp av mypy-demonen. Demonen är en serverprocess som implementerar två intressanta funktioner. För det första - den håller all information om hela kodbasen i minnet. Detta innebär att mypy inte behöver ladda cachad data som rör tusentals importerade beroenden vid varje körning. För det andra - den analyserar noggrant, på en detaljerad strukturell nivå, relationerna mellan funktioner och andra entiteter. Till exempel, om funktionen foo anropar funktionen bar, finns det ett beroende foo från bar. När en fil ändras, bearbetar demonen först, i isolering, bara den ändrade filen. Därefter tittar den på förändringarna i denna fil som är synliga utanför, på sådant som ändrade funktionssignaturer. Demonen använder detaljerad information om importer endast för att dubbelkolla de funktioner som verkligen använder den ändrade funktionen. Vanligtvis behöver man kontrollera ganska få funktioner med denna metod.

Genomförandet av allt detta var ingen lätt uppgift, eftersom den ursprungliga implementationen av mypy var starkt inriktad på att bearbeta en fil i taget. Vi stötte på många gränsytor där det var nödvändigt med upprepade kontroller när något förändrades i koden. Till exempel händer detta när en klass får en ny basklass. Efter att vi gjort det vi ville kunde vi minska tiden för de flesta inkrementella kontroller till några sekunder. Detta kändes som en stor seger för oss.

Ännu mer prestanda!

Tillsammans med den fjärrcache som jag nämnde tidigare har mypy-demonen i stort sett helt löst problemen som uppstår när en programmerare ofta kör typkontroller medan de gör ändringar i ett fåtal filer. Dock var systemets prestanda i det minst gynnsamma användningsscenariot fortfarande långt ifrån optimal. En ren körning av mypy kunde ta över 15 minuter. Detta var långt mer än vad vi skulle vara nöjda med. Varje vecka blev situationen värre, eftersom programmerarna fortsatte att skriva ny kod och lägga till anteckningar till den befintliga koden. Våra användare längtade fortfarande efter mer prestanda, och vi var mer än villiga att möta deras förväntningar.

Vi bestämde oss för att återvända till en av de tidiga idéerna om mypy. Närmare bestämt att konvertera Python-kod till C-kod. Experiment med Cython (ett system som gör det möjligt att översätta kod skriven i Python till C-kod) gav oss ingen synlig prestandaförbättring, så vi beslutade oss för att väcka idén om att skriva en egen kompilator. Eftersom mypy:s kodbas (skriven i Python) redan innehöll alla nödvändiga typannoteringar, verkade det värt att försöka använda dessa annoteringar för att snabba upp systemets arbete. Jag skapade snabbt en prototyp för att testa denna idé. Den visade mer än tiofaldig prestanda på olika mikrobänkar. Vår idé var att kompilera Python-moduler till C-moduler med hjälp av Cython, och att omvandla typannoteringar till typkontroller som utförs under programmets körning (vanligtvis ignoreras typannoteringar vid körning och används endast av typkontrolleringssystem). Vi planerade faktiskt att översätta implementeringen av mypy från Python till ett språk som var statiskt typat och som skulle se ut (och i de flesta fall fungera) precis som Python. (Denna typ av språkövergång har blivit något av en tradition för mypy-projektet. Den ursprungliga implementeringen av mypy skrevs i Alore, följd av en syntaxhybrid mellan Java och Python).

Fokus på CPython:s API:er var nyckeln till att inte förlora möjligheter till projektledning. Vi behövde inte implementera en virtuell maskin eller några bibliotek som mypy behövde. Dessutom skulle vi fortfarande ha tillgång till hela Python-ekosystemet, inklusive alla verktyg (som pytest). Detta innebar att vi skulle kunna fortsätta använda tolkad Python-kod under utvecklingen, vilket skulle tillåta oss att arbeta med en mycket snabb kodändrings- och testningscykel, istället för att vänta på kodkompilering. Det kändes som att vi framgångsrikt kunde sitta på två stolar, och vi gillade det.

Kompilatoren som vi kallade mypyc (eftersom den använder mypy för typanalys som frontend) har visat sig vara ett ganska framgångsrikt projekt. Totalt sett har vi uppnått ungefär en 4-faldig ökning av hastigheten vid frekventa körningar av mypy utan att använda cache. Utvecklingen av kärnan i mypyc tog en liten grupp, bestående av Michael Sullivan, Ivan Levkivskyi, Hugh Han och jag, cirka 4 kalender månader. Denna arbetsinsats var mycket mindre omfattande än vad som skulle krävas för att skriva om mypy, till exempel i C++ eller Go. Och vi behövde också göra betydligt färre förändringar i projektet än vi skulle ha behövt om vi skrivit om det på ett annat språk. Dessutom hoppades vi att vi skulle kunna ta mypyc till en nivå där andra programmerare från Dropbox skulle kunna använda det för att kompilera och påskynda sin kod.

För att uppnå en sådan prestandanivå var vi tvungna att tillämpa några intressanta ingenjörslösningar. Kompilatorn kan påskynda utförandet av många operationer genom att använda snabba låg nivå C-konstruktioner. Till exempel översätts ett anrop av en kompilerad funktion till ett anrop av en C-funktion. Och ett sådant anrop utförs mycket snabbare än ett anrop av en tolkad funktion. Vissa operationer, som sökningar i ordböcker, återgick fortfarande till att använda vanliga anrop av C-API från CPython, vilka efter kompileringen bara var något snabbare. Vi lyckades eliminera den extra belastningen på systemet som skapades av tolkning, men detta gav endast en liten prestandaförbättring i det här fallet.

För att identifiera de mest förekommande "långsamma" operationerna utförde vi en profilering av koden. Med de insamlade uppgifterna försökte vi antingen justera mypyc för att generera snabbare C-kod för sådana operationer, eller skriva om motsvarande Python-kod med hjälp av snabbare operationer (ibland hade vi helt enkelt inte någon enkel lösning för något problem). Att skriva om Python-koden visade sig ofta vara en enklare lösning på problemet än att implementera en automatisk utförande av samma transformation i kompileraren. På lång sikt ville vi automatisera många av dessa transformationer, men för tillfället var vi fokuserade på att with minimal effort accelerera mypy. Med den ambitionen skar vi några hörn.

Fortsättning följer…

Kära läsare! Vilka intryck fick projektet mypy när du först fick kännedom om dess existens?

Källa: habr.com