ហេតុអ្វីបានជាការបែងចែក C++ (m) ដំបូងតែងតែ 72 KB?

អាថ៌កំបាំងនៅពីក្រោយការបែងចែក C++ ដំបូងរបស់អ្នក

អ្នកសរសេរកម្មវិធី C++ សាមញ្ញ។ ថ្មី int តែមួយ។ បួនបៃ។ អ្នកចាប់ផ្តើមដំណើរការ strace ឬកម្មវិធីផ្ទុកអង្គចងចាំដែលអ្នកចូលចិត្ត ហើយវាគឺ — ដំណើរការរបស់អ្នកទើបតែបានស្នើសុំប្រហែល 72 KB ពីប្រព័ន្ធប្រតិបត្តិការ។ មិនមែន 4 បៃទេ។ មិនមែន 64 បៃទេ។ ពេញ 72 KB ។ ប្រសិនបើអ្នកធ្លាប់សម្លឹងមើលលេខនោះ ហើយឆ្ងល់ថាតើឧបករណ៍របស់អ្នកកំពុងកុហកអ្នកឬអត់នោះ អ្នកមិននៅម្នាក់ឯងទេ។ អាកប្បកិរិយាដែលហាក់ដូចជាចម្លែកនេះគឺជាសំណួរមួយក្នុងចំណោមសំណួរដែលគេសួរញឹកញាប់បំផុតក្នុងចំណោមអ្នកអភិវឌ្ឍន៍ C++ ដែលជីកចូលទៅក្នុងអង្គចងចាំខាងក្នុងជាលើកដំបូង ហើយចម្លើយនាំយើងទៅកាន់ដំណើរដ៏គួរឱ្យចាប់អារម្មណ៍តាមរយៈស្រទាប់ដែលស្ថិតនៅចន្លោះកូដរបស់អ្នក និងផ្នែករឹងពិតប្រាកដ។

តើមានអ្វីកើតឡើងនៅពេលអ្នកហៅ ថ្មី

ដើម្បីយល់ពីតួលេខ 72 KB អ្នកត្រូវតាមដានខ្សែសង្វាក់បែងចែកពេញលេញ។ នៅពេលដែលកូដ C++ របស់អ្នកប្រតិបត្តិ int ថ្មី កម្មវិធីចងក្រងបកប្រែវាទៅជាការហៅទៅកាន់ operator new ដែលនៅលើប្រព័ន្ធលីនុចភាគច្រើនផ្ទេរទៅ malloc ពី glibc ។ ប៉ុន្តែ malloc មិនសួរខឺណែលដោយផ្ទាល់សម្រាប់អង្គចងចាំ 4 បៃទេ។ ខឺណែលដំណើរការក្នុងទំព័រ — ជាធម្មតា 4 KB នៅលើ x86_64 — ហើយតម្លៃនៃការហៅប្រព័ន្ធគឺធំសម្បើមទាក់ទងទៅនឹងការចូលប្រើអង្គចងចាំធម្មតា។ ការហៅទូរសព្ទទៅ brk() ឬ mmap() សម្រាប់រាល់ការបែងចែកបុគ្គលនឹងធ្វើឱ្យកម្មវិធីដែលមិនសំខាន់ណាមួយត្រូវផ្អាក។

ជំនួសមកវិញ ឧបករណ៍បែងចែកការចងចាំរបស់ glibc — ការអនុវត្តមួយហៅថា ptmalloc2 ខ្លួនវាចុះមកពី dlmalloc បុរាណរបស់ Doug Lea — ដើរតួជាឈ្មួញកណ្តាល។ វាស្នើសុំប្លុកធំនៃអង្គចងចាំពីខឺណែលខាងមុខ បន្ទាប់មកឆ្លាក់ពួកវាទៅជាបំណែកតូចៗតាមដែលកម្មវិធីរបស់អ្នកត្រូវការវា។ នេះគឺជាហេតុផលជាមូលដ្ឋានដែលការបែងចែក 4 បៃដំបូងរបស់អ្នកបង្កឱ្យមានសំណើធំជាងនេះទៅប្រព័ន្ធប្រតិបត្តិការ។ អ្នកបែងចែកមិនខ្ជះខ្ជាយទេ។ វា​គឺ​ជា​យុទ្ធសាស្ត្រ។

បំបែក 72 KB៖ កន្លែងដែលបៃទៅ

ការ​បែងចែក​ការ​ចំណាយ​ដំបូង​ចេញ​មក​ពី​សមាសធាតុ​ខុស​គ្នា​មួយ​ចំនួន​ដែល​ពេល​រត់​ត្រូវ​តែ​ចាប់ផ្ដើម​មុន​ពេល​ដែល​វា​អាច​ផ្ដល់​ឱ្យ​អ្នក​សូម្បី​តែ​មួយ​បៃ​នៃ​អង្គ​ចងចាំ​ដែល​អាច​ប្រើ​បាន​។ ការយល់ដឹងអំពីសមាសធាតុនីមួយៗពន្យល់ពីមូលហេតុដែលលេខនោះមកកន្លែងដែលវាកើតឡើង។

ជាដំបូង ហាងទំនិញរបស់ glibc ចាប់ផ្តើម សង្វៀនចម្បង ដែលជារចនាសម្ព័ន្ធរក្សាបញ្ជីបឋមដែលតាមដានការបែងចែកទាំងអស់នៅលើបណ្តាញមេ។ វេទិកានេះរួមបញ្ចូលទិន្នន័យមេតាសម្រាប់ heap ទ្រនិចបញ្ជីឥតគិតថ្លៃ និងរចនាសម្ព័ន្ធធុងសម្រាប់ទំហំបែងចែកផ្សេងៗគ្នា។ អ្នកបែងចែកបន្តការបំបែកកម្មវិធីតាមរយៈ sbrk() ហើយផ្នែកបន្ថែមដំបូងត្រូវបានគ្រប់គ្រងដោយប៉ារ៉ាម៉ែត្រខាងក្នុងហៅថា M_TOP_PAD ដែលកំណត់លំនាំដើមដល់ 128 KB នៃ padding ។ ទោះជាយ៉ាងណាក៏ដោយ សំណើដំបូងពិតប្រាកដត្រូវបានកែសម្រួលសម្រាប់ការតម្រឹមទំព័រ និងទីតាំងបំបែកដែលមានស្រាប់ ដែលជារឿយៗនាំឱ្យសំណើដំបូងតូចជាង — ជាទូទៅគឺនៅជិតតួរលេខ 72 KB នៅលើដំណើរការដែលទើបចាប់ផ្តើមថ្មីៗ។

ទីពីរ ចាប់តាំងពី glibc 2.26 អ្នកបែងចែកចាប់ផ្តើម thread-local cache (tcache) នៅពេលប្រើលើកដំបូង។ ឃ្លាំងសម្ងាត់មាន 64 bins (មួយក្នុងមួយថ្នាក់ទំហំតូចបែងចែក) ដែលនីមួយៗអាចផ្ទុកបានរហូតដល់ 7 កំណាត់។ tcache_perthread_struct ខ្លួន​វា​ប្រើប្រាស់​ប្រហែល 1 KB ប៉ុន្តែ​សកម្មភាព​នៃ​ការ​ចាប់​ផ្តើម​វា​បង្ក​ឱ្យ​មាន​ការ​ដំឡើង​សង្វៀន​ទូលំទូលាយ។ ទីបី ពេលវេលាដំណើរការ C++ បានអនុវត្តការបែងចែករួចហើយ មុនពេល main() របស់អ្នកដំណើរការ — static constructors, iostream buffer initialization for std::cout and friends, and locale setup ទាំងអស់រួមចំណែកដល់ heap footprint ដំបូងនោះ។

ប្រព័ន្ធសង្វៀន និងមូលហេតុដែលការបែងចែកជាមុនគឺឆ្លាតវៃ

ការសម្រេច​ចិត្ត​បែងចែក​បណ្តុំ​នៃ​ការ​ចងចាំ​ជា​ជាង​ការ​ស្នើ​សុំ​វា​ជា​ដុំៗ មិនមែនជា​ឧបទ្ទវហេតុ​នៃ​ការអនុវត្ត​នោះទេ។ វាគឺជាការដោះដូរផ្នែកវិស្វកម្មដោយចេតនាដែលមានឫសគល់នៅក្នុងបទពិសោធន៍នៃការសរសេរកម្មវិធីប្រព័ន្ធជាច្រើនទសវត្សរ៍។ រាល់ការហៅទៅកាន់ brk() ឬ mmap() ពាក់ព័ន្ធនឹងការប្តូរបរិបទពីទំហំអ្នកប្រើប្រាស់ទៅទំហំខឺណែល ការកែប្រែការគូសផែនទីសតិនិម្មិតរបស់ដំណើរការ និងការធ្វើបច្ចុប្បន្នភាពតារាងទំព័រសក្តានុពល។ នៅលើផ្នែករឹងទំនើប ការហៅតាមប្រព័ន្ធតែមួយមានតម្លៃប្រហែល 100-200 ណាណូវិនាទី — មិនសំខាន់ក្នុងភាពឯកោ គ្រោះមហន្តរាយតាមមាត្រដ្ឋាន។

ពិចារណាកម្មវិធីដែលបង្កើតការបែងចែកតូចៗចំនួន 10,000 កំឡុងពេលចាប់ផ្តើម។ បើគ្មានការបែងចែកជាមុន នោះមានន័យថា 10,000 ការហៅទូរស័ព្ទតាមប្រព័ន្ធ ចំណាយប្រហែល 1-2 មិល្លីវិនាទីនៃការចំណាយសុទ្ធ។ ជាមួយនឹងអ្នកបែងចែកដែលមានមូលដ្ឋានលើសង្វៀន ការបែងចែកដំបូងបង្កឱ្យមានការហៅជាប្រព័ន្ធតែមួយ ហើយការបែងចែក 9,999 ជាបន្តបន្ទាប់ត្រូវបានផ្តល់សេវាកម្មទាំងស្រុងក្នុងចន្លោះអ្នកប្រើប្រាស់តាមរយៈប្រតិបត្តិការលេខនព្វន្ធ និងបញ្ជីភ្ជាប់ ដែលនីមួយៗចំណាយពេលប្រហែល 10-50 ណាណូវិនាទី។ គណិត​វិទ្យា​គឺ​មិន​ច្បាស់​លាស់៖ ការ​បែងចែក​មុន​ឈ្នះ​តាម​លំដាប់​នៃ​ទំហំ។

ទំហំ 72 KB ដែលអ្នកឃើញនៅលើការបែងចែកដំបូងរបស់អ្នកគឺមិនត្រូវបានខ្ជះខ្ជាយការចងចាំនោះទេ វាគឺជាការវិនិយោគលើការអនុវត្ត។ អ្នកបែងចែកកំពុងភ្នាល់ថាកម្មវិធីរបស់អ្នកនឹងធ្វើការបែងចែកបន្ថែមទៀតក្នុងពេលឆាប់ៗនេះ ហើយនៅក្នុងស្ទើរតែគ្រប់ស្ថានភាពជាក់ស្តែង ការភ្នាល់នោះនឹងទូទាត់យ៉ាងស្អាត។ តម្លៃ​នៃ​ទំហំ​អាសយដ្ឋាន​និម្មិត​ដែល​មិន​បាន​ប្រើ​គឺ​សូន្យ​លើ​ប្រព័ន្ធ 64 ប៊ីត​ទំនើប។

សតិ​និម្មិត​ធៀប​នឹង​ការ​ចងចាំ​រូបវិទ្យា៖ ហេតុអ្វី​វា​មិន​សំខាន់

កង្វល់ទូទៅក្នុងចំណោមអ្នកអភិវឌ្ឍន៍ដែលជួបប្រទះអាកប្បកិរិយានេះជាលើកដំបូងគឺការខ្ជះខ្ជាយធនធាន។ ប្រសិនបើខ្ញុំត្រូវការត្រឹមតែ 4 បៃ ហេតុអ្វីបានជាកម្មវិធីរបស់ខ្ញុំប្រើប្រាស់ 72 KB? ការយល់ដឹងសំខាន់គឺថា ការចងចាំនិម្មិតមិនមែនជាការចងចាំរាងកាយ។ នៅពេលដែល glibc ពង្រីកការបំបែកកម្មវិធីដោយ 72 KB ខឺណែលធ្វើបច្ចុប្បន្នភាពការគូសផែនទីសតិនិម្មិតរបស់ដំណើរការ ប៉ុន្តែវាមិនត្រលប់មកវិញភ្លាមៗនូវទំព័រទាំងនោះជាមួយនឹង RAM រាងកាយទេ។ ទំព័រជាក់ស្តែងត្រូវបានបែងចែកតាមតម្រូវការតាមរយៈ កំហុសទំព័រ - លុះត្រាតែកម្មវិធីរបស់អ្នកសរសេរទៅអាសយដ្ឋានជាក់លាក់មួយ តើខឺណែលផ្តល់ទំព័រពិតនៃការចងចាំទៅវាទេ។

នេះមានន័យថា ទោះបីជាទំហំនិម្មិតនៃដំណើរការរបស់អ្នកកើនឡើង 72 KB ក៏ដោយ ទំហំកំណត់អ្នករស់នៅ (RSS) របស់វា — ចំនួន RAM ជាក់ស្តែងដែលប្រើប្រាស់ — កើនឡើងត្រឹមតែទំព័រដែលអ្នកពិតជាប៉ះប៉ុណ្ណោះ។ សម្រាប់ Int ថ្មី តែមួយ នោះជាធម្មតាមានទំព័រ 4 KB មួយ បូកនឹងទំព័រណាក៏ដោយដែលទិន្នន័យមេតារបស់ Arena កាន់កាប់។ ទំហំ​និម្មិត​ដែល​នៅ​សល់​អង្គុយ​នៅ​ទីនោះ​រួចរាល់​សម្រាប់​ការ​ប្រើ​ប្រាស់ ដោយ​មិន​ចំណាយ​អ្វី​ក្រៅ​ពី​ទំហំ​អាសយដ្ឋាន — ដែល​អ្នក​មាន 128 TB នៅ​លើ​ប្រព័ន្ធ​លីនុច 64 ប៊ីត។

ភាពខុសគ្នានេះគឺមានសារៈសំខាន់នៅពេលបង្កើតទម្រង់ និងត្រួតពិនិត្យកម្មវិធីផលិតកម្ម។ ប្រសិនបើអ្នកកំពុងបង្កើតកម្មវិធីដែលត្រូវការតាមដានការប្រើប្រាស់ធនធានពិតប្រាកដ — ថាតើវាជាផ្នែកខាងក្រោយ SaaS សេវាមីក្រូ ឬបំពង់បង្ហូរវិភាគដូចកម្មវិធីដែលដំណើរការលើវេទិកាដូចជា Mewayz សម្រាប់ប្រតិបត្តិការអាជីវកម្ម — អ្នកគួរតែតាមដាន RSS ជាជាងទំហំនិម្មិត។ ឧបករណ៍​ដូចជា /proc/[pid]/smaps, valgrind --tool=massif និង pmap អាច​ផ្តល់ឱ្យ​អ្នក​នូវ​ដាន​សតិពិត​ត្រឹមត្រូវ​ជាជាង​បំភាន់​តួលេខ​អង្គចងចាំ​និម្មិត។

របៀបដែលអ្នកបែងចែកផ្សេងគ្នាដោះស្រាយការបែងចែកដំបូង

តួលេខ 72 KB គឺជាក់លាក់ចំពោះ ptmalloc2 របស់ glibc ។ អ្នកបែងចែកផ្សេងទៀតបង្កើតការដោះដូរផ្សេងៗគ្នា ហើយការបែងចែកដំបូងក៏ប្រែប្រួលទៅតាមនោះដែរ។ ការ​យល់​ពី​ភាព​ខុស​គ្នា​ទាំង​នេះ​គឺ​មាន​តម្លៃ​នៅ​ពេល​ជ្រើសរើស​អ្នក​បែង​ចែក​សម្រាប់​កម្មវិធី​ដែល​មាន​ប្រសិទ្ធភាព។

• jemalloc (ប្រើដោយ Facebook, FreeBSD) — ប្រើរចនាសម្ព័ន្ធសង្វៀនដែលមានលក្ខណៈជាក្រឡាបន្ថែមទៀតជាមួយនឹងឃ្លាំងសម្ងាត់ក្នុងតំបន់។ ថ្លៃដើមដំបូងមានទំនោរខ្ពស់ជាង (ជាញឹកញាប់ 200+ KB) ប៉ុន្តែផ្តល់នូវដំណើរការពហុខ្សែប្រសើរជាងមុន ដោយសារការកាត់បន្ថយការប៉ះទង្គិចគ្នា។
• tcmalloc (Google's Thread-Caching Malloc) — បែងចែកឃ្លាំងសម្ងាត់ក្នុងមួយខ្សែដែលមានទំហំប្រហែល 2 MB តាមលំនាំដើម ជាមួយនឹងការបែងចែកជាមុនយ៉ាងធ្ងន់ធ្ងរ។ ថ្លៃដើមដំបូងគឺខ្ពស់ជាង ប៉ុន្តែការបែងចែកតូចៗជាបន្តបន្ទាប់គឺលឿនណាស់។
• malloc របស់ musl libc — ប្រើការរចនាសាមញ្ញជាងដោយផ្អែកលើ mmap សម្រាប់ការបែងចែកទាំងអស់។ ថ្លៃដើមដំបូងគឺតិចតួចបំផុត (ជាញឹកញាប់ត្រឹមតែ 4 KB ក្នុងមួយការបែងចែក) ប៉ុន្តែការចំណាយក្នុងមួយការបែងចែកគឺខ្ពស់ជាងដោយសារការហៅតាមប្រព័ន្ធញឹកញាប់ជាងមុន។
• mimalloc (Microsoft) — ប្រើការបែងចែកតាមផ្នែកដែលមានផ្នែក 64 MB ។ ការបែងចែកដំបូងបង្កឱ្យមានការកក់និម្មិត 64 មេកាបៃ (ដោយមានការប្តេជ្ញាចិត្តតិចតួចបំផុត) ទំហំអាសយដ្ឋានពាណិជ្ជកម្មសម្រាប់តំបន់ពិសេស និងលំហូរចូល។

ជម្រើសរវាងអ្នកបែងចែកទាំងនេះអាស្រ័យទាំងស្រុងលើបន្ទុកការងាររបស់អ្នក។ សម្រាប់​កម្មវិធី​ម៉ាស៊ីនមេ​ដែល​ដំណើរការ​យូរ​ជាមួយ​នឹង​ការ​បែងចែក​ច្រើន​ខ្សែ​ខ្លាំង jemalloc ឬ tcmalloc ជាធម្មតា​ដំណើរការ​លំនាំដើម​របស់ glibc។ សម្រាប់​ប្រព័ន្ធ​បង្កប់​ដែល​មាន​ការ​រឹត​បន្តឹង​ការ​ចងចាំ វិធីសាស្ត្រ​សាមញ្ញ​របស់ musl អាច​ជា​ការ​ល្អ​ប្រសើរ​បើ​ទោះ​បី​ជា​កម្រិត​បញ្ជូន​ទាប​ក៏​ដោយ។ សម្រាប់​កម្មវិធី​កុំព្យូទ័រ និង​ម៉ាស៊ីនមេ​ដែល​មាន​គោលបំណង​ទូទៅ ការចំណាយ​ដំបូង 72 KB របស់ ptmalloc2 តំណាង​ឱ្យ​លំនាំដើម​សមហេតុផល​ដែល​ដំណើរការ​បានល្អ​ដោយ​មិន​មានការ​កែសម្រួល។

ការលៃតម្រូវ​ឥរិយាបថ​ការ​បែងចែក​ដំបូង

ប្រសិនបើតម្លៃដើមដំបូង 72 KB មានបញ្ហាពិតប្រាកដសម្រាប់ករណីប្រើប្រាស់របស់អ្នក — ប្រហែលជាអ្នកកំពុងបង្កើតដំណើរការរយៈពេលខ្លីរាប់ពាន់ ដែលនីមួយៗបង្កើតបានតែមួយចំនួនតូចប៉ុណ្ណោះ — glibc ផ្តល់នូវការលៃតម្រូវជាច្រើនតាមរយៈ mallopt() និង MALLOC_ family of environment variables

ប៉ារ៉ាម៉ែត្រ M_TOP_PAD គ្រប់គ្រងចំនួនអង្គចងចាំបន្ថែមដែលអ្នកបែងចែកស្នើសុំលើសពីអ្វីដែលត្រូវការភ្លាមៗ។ ការកំណត់វាទៅជា 0 ជាមួយ mallopt(M_TOP_PAD, 0) ប្រាប់អ្នកបែងចែកឱ្យស្នើសុំតែអ្វីដែលចាំបាច់ ដោយកាត់បន្ថយការចំណាយដំបូងយ៉ាងខ្លាំង។ ប៉ារ៉ាម៉ែត្រ M_MMAP_THRESHOLD គ្រប់គ្រងទំហំខាងលើដែលការបែងចែកប្រើ mmap ជំនួសឱ្យសង្វៀន។ M_TRIM_THRESHOLD គ្រប់គ្រងនៅពេលដែលអង្គចងចាំទំនេរត្រូវបានបញ្ជូនត្រឡប់ទៅប្រព័ន្ធប្រតិបត្តិការវិញ។ ហើយចាប់តាំងពី glibc 2.26 ការលៃតម្រូវ glibc.malloc.tcache_count និង glibc.malloc.tcache_max អនុញ្ញាតឱ្យអ្នកគ្រប់គ្រងឥរិយាបថឃ្លាំងសម្ងាត់ខ្សែស្រឡាយ។

ទោះជាយ៉ាងនេះក្តី ពាក្យនៃការប្រុងប្រយ័ត្ន៖ ការលៃតម្រូវប៉ារ៉ាម៉ែត្រទាំងនេះដោយមិនមានការវាយតម្លៃដោយប្រុងប្រយ័ត្ន ស្ទើរតែតែងតែធ្វើឱ្យអ្វីៗកាន់តែអាក្រក់ទៅៗ។ លំនាំដើម​ត្រូវ​បាន​ជ្រើសរើស​ដោយ​ផ្អែក​លើ​ទម្រង់​ពិភព​ពិត​ដ៏​ទូលំទូលាយ ហើយ​វា​តំណាង​ឱ្យ​កន្លែង​ដ៏​ផ្អែមល្ហែម​សម្រាប់​បន្ទុក​ការងារ​ភាគច្រើន។ លុះត្រាតែអ្នកមានភ័ស្តុតាងរឹងមាំពីការបង្កើតទម្រង់ផលិតកម្មដែលថា malloc លើសក្បាលគឺជាឧបសគ្គ - ហើយអ្នកបានវាស់វែងផលប៉ះពាល់នៃការផ្លាស់ប្តូររបស់អ្នក - ទុកលំនាំដើមតែម្នាក់ឯង។ ការបង្កើនប្រសិទ្ធភាពមុនពេលកំណត់នៃអ្នកបែងចែកគឺជាទម្រង់នៃការកោរសក់យ៉ាកដ៏ឃោឃៅបំផុត ដែលបានប្រើប្រាស់ម៉ោងវិស្វកម្មរាប់មិនអស់សម្រាប់អត្ថប្រយោជន៍ដែលធ្វេសប្រហែស។

អ្វីដែលវាបង្រៀនយើងអំពីការសរសេរកម្មវិធីប្រព័ន្ធ

អាថ៌កំបាំងនៃការបែងចែកដំបូង 72 KB គឺជាមេរៀនមួយអំពី ស្រទាប់អរូបី។ C++ ផ្តល់ឱ្យអ្នកនូវការបំភាន់ថា int ថ្មី បែងចែក 4 បៃ។ ស្តង់ដារភាសានិយាយដូច្នេះ។ គំរូផ្លូវចិត្តរបស់អ្នកនិយាយដូច្នេះ។ ប៉ុន្តែរវាងកូដរបស់អ្នក និងផ្នែករឹងមានប្រព័ន្ធស្មុគ្រស្មាញជាច្រើន — ពេលវេលាដំណើរការ C++, C library allocator, ប្រព័ន្ធរងនៃសតិនិម្មិតរបស់ខឺណែល និង MMU និង TLB របស់ hardware — នីមួយៗបន្ថែមអាកប្បកិរិយា ការបង្កើនប្រសិទ្ធភាព និងការចំណាយផ្ទាល់ខ្លួនរបស់វា។

នេះមិនមែនជាកំហុសទេ។ វាគឺជាចំណុចទាំងមូលនៃកម្មវិធីប្រព័ន្ធ។ ស្រទាប់នីមួយៗមានដើម្បីដោះស្រាយបញ្ហាពិតប្រាកដ៖ អ្នកបែងចែកមាន ដូច្នេះអ្នកមិនចាំបាច់ធ្វើការហៅប្រព័ន្ធសម្រាប់រាល់ការបែងចែកនោះទេ។ ប្រព័ន្ធសតិនិម្មិតមាន ដូច្នេះអ្នកមិនចាំបាច់គ្រប់គ្រងអង្គចងចាំដោយផ្ទាល់ទេ។ កម្មវិធីដោះស្រាយកំហុសទំព័រមាន ដូច្នេះការចងចាំត្រូវបានប្រព្រឹត្តដោយខ្ជិល និងមានប្រសិទ្ធភាព។ ស្រទាប់នីមួយៗធ្វើការជួញដូរនូវតម្លាភាពតិចតួចសម្រាប់ចំនួនដ៏ច្រើននៃការអនុវត្ត និងភាពងាយស្រួល។

អ្នកអភិវឌ្ឍន៍ដែលបង្កើតប្រព័ន្ធដែលគួរឱ្យទុកចិត្តបំផុត និងដំណើរការខ្ពស់បំផុត គឺជាអ្នកដែលយល់ពីស្រទាប់ទាំងនេះ មិនមែនដោយសារតែពួកគេត្រូវគិតអំពីពួកវាជានិច្ចនោះទេ ប៉ុន្តែដោយសារតែនៅពេលដែលមានអ្វីដែលមិននឹកស្មានដល់កើតឡើង (ដូចជាការបែងចែក 72 KB ដ៏អាថ៌កំបាំង) ពួកគេមានគំរូផ្លូវចិត្តដើម្បីយល់ពីមូលហេតុ។ មិនថាអ្នកកំពុងបង្កើតប្រព័ន្ធពាណិជ្ជកម្មតាមពេលវេលាជាក់ស្តែង ម៉ាស៊ីនហ្គេម ឬវេទិកាអាជីវកម្មដែលបម្រើអ្នកប្រើប្រាស់រាប់ពាន់នាក់នោះទេ សមត្ថភាពក្នុងការវែកញែកអំពីអ្វីដែលកូដរបស់អ្នកពិតជាធ្វើនៅកម្រិតប្រព័ន្ធ គឺជាអ្វីដែលបំបែកអ្នកអភិវឌ្ឍន៍ដែលមានសមត្ថភាពពីអ្នកអភិវឌ្ឍន៍ពិសេស។ 72 KB មិនមែនជាកំហុសទេ។ វា​គឺ​ជា​អ្នក​បែង​ចែក​របស់​អ្នក​ធ្វើ​ការ​ងារ​របស់​វា​យ៉ាង​អស្ចារ្យ។