fmmap weergawe 2.0.0 | Friedel Wolff
fmmap weergawe 2.0.0
Ek het omtrent twee maande gelede fmmap op my webjoernaal bekendgestel. fmmap is 'n Python-module wat in die plek van die ingeboude mmap-module gebruik kan word en beter werkverrigting bied. Ek het weergawe 2.0.0 onlangs vrygestel en wou sommige van die afgelope twee maande se verbeterings deel.
Ek het 'n .rfind()-metode geïmplementeer wat gewoonlik heelwat vinniger is as die ingeboude implementasie. Daar is 'n skrip op github om die werkverrigting van .find() en .rfind() met CPython te vergelyk. Toekomstige weergawes gee waarskynlik nog meer aandag aan werkverrigting.
Vergeleke met die aanvang op my Linux-werkstasie, word die projek nou getoets op 'n klomp bedrystelsels:
Solaris (ek het op illumos/OpenIndiana getoets)
Die stelsels vir kontinue integrasie toets tans op Ubuntu 16.04 en 18.04, macOS 10.15 en Windows Server 2019. Verder toets ek met die hand op Mageia 7, RHEL 7, FreeBSD 11.3, NetBSD 8.2, OpenBSD 6.6, OpenIndiana 5.11, macOS 10.14 en Windows 10. Die stelsels vir kontinue integrasie en heelwat van die Unix-stelsels word op virtuele masjiene getoets.
Die projek ondersteun nou platforms wat nie die soekfunksies in die C-biblioteek het wat fmmap gebruik nie. Dit was nodig om Solaris, macOS en Windows te ondersteun.
Adviesparameters vir madvise(2) op alle ondersteunde platforms is bygevoeg — om hulle beskikbaar te maak in ouer Python-weergawes, maar om ook stelselspesifieke waardes te ondersteun wat nie deur CPython ondersteun word nie.
Die projek ondersteun nou Python weergawes 3.4–3.9. Nie alle kombinasies van bedryfstelsel en Python-weergawe word getoets nie, maar uit die 7 × 6-matriks (bedryfstelsel × Python-weergawes, 42 kombinasies) word 23 kombinasies getoets. Alhoewel daar ruimte is vir verbetering, is heelwat van die ongetoetste kombinasies vir Python 3.4 (wat deur meeste platforms nie ondersteun word nie) en vir Python 3.9 (wat nog nie amptelik vrygestel is nie). As dié twee weergawes geïgnoreer word, word 20 uit die 28 kombinasies getoets.
Ek het nog 'n paar dinge in gedagte vir die toekoms. Alhoewel ek meestal tevrede is met die soekspoed, is daar steeds ruimte vir verbetering weens die wisselende spoedeienskappe van die funksies in die C-biblioteke. (Ek het deur die relevante implementasies van al die C-biblioteke met beskikbare kode gelees.) Ek is onseker of verdere werk aan werkverrigting die moeite werd is, maar miskien is betekenisvolle verbeteringe steeds moontlik. Alhoewel soekspoed die aanvanklike rede vir die projek was, oorweeg ek ook op die programmeerkoppelvlak (API) effens uit te brei om enkele gebruike van geheue-afbeelding te ondersteun.