නොමේරූ ප්‍රශස්තකරණය සැබවින්ම සියලු නපුරේ මුලද?

අද මගේ සගයකු විසින් පංතියක් සිදු ThreadLocalFormatකරන ලද අතර එය මූලික වශයෙන් ජාවා ෆෝමැට් පංති දේශීය නූල් බවට ගෙන ගියේය, මන්ද ඒවා නූල් ආරක්ෂිත නොවන අතර නිර්මාණය කිරීමට “සාපේක්ෂව මිල අධික” ය. මම ඉක්මන් පරීක්‍ෂණයක් ලියා තත්පරයට අවස්ථා 200,000 ක් නිර්මාණය කළ හැකි යැයි ගණනය කළෙමි. ඔහු ඇසුවේ ඔහු බොහෝ දේ නිර්මාණය කරනවාද යන්නයි. එයට ඔහු පිළිතුරු දුන්නේ “එතරම් ගණනකට කොතැනකවත් නැත” යනුවෙනි. ඔහු විශිෂ් program ක්‍රමලේඛකයෙක් වන අතර කණ්ඩායමේ සිටින සියල්ලන්ම ඉතා දක්ෂ බැවින් ප්‍රති ing ල කේතය තේරුම් ගැනීමට අපට කිසිදු ගැටළුවක් නොමැත, නමුත් එය පැහැදිලිවම සැබෑ අවශ්‍යතාවයක් නොමැති තැන ප්‍රශස්තිකරණය කිරීමේ අවස්ථාවකි. ඔහු මගේ ඉල්ලීම පරිදි කේතයට පිටුබලය දුන්නේය. ඔයා සිතන්නේ කුමක් ද? මෙය "නොමේරූ ප්‍රශස්තිකරණය" පිළිබඳ සිද්ධියක් වන අතර එය ඇත්ත වශයෙන්ම කෙතරම් නරකද?

සම්පූර්ණ උපුටා දැක්වීම මතකයේ තබා ගැනීම වැදගත් ය:

කුඩා කාර්යක්ෂමතාවයන් ගැන අප අමතක කළ යුතුය, කාලය 97% ක් පමණ කියන්න: නොමේරූ ප්‍රශස්තකරණය සියලු නපුරේ මුල වේ. එහෙත් එම තීරණාත්මක 3% තුළ අප අපගේ අවස්ථාවන් අත් නොහැරිය යුතුය.

මෙයින් අදහස් කරන්නේ, මනින ලද කාර්ය සාධන ගැටළු නොමැති විට ඔබ ප්‍රශස්තිකරණය නොකළ යුත්තේ ඔබට කාර්ය සාධන ලාභයක් ලැබෙනු ඇතැයි සිතන බැවිනි . පැහැදිලි ප්‍රශස්තිකරණයන් ඇත (තද පුඩුවක් තුළ නූල් සම්මුතියක් සිදු නොකිරීම වැනි) නමුත් සුළු වශයෙන් පැහැදිලි ප්‍රශස්තිකරණයක් නොවන ඕනෑම දෙයක් මැනිය හැකි තෙක් එය වළක්වා ගත යුතුය.

"නොමේරූ ප්‍රශස්තිකරණය" සමඟ ඇති ලොකුම ගැටළුව නම්, එය අනපේක්ෂිත දෝෂ හඳුන්වා දිය හැකි අතර විශාල කාලයක් නාස්ති කිරීමක් විය හැකිය.

නොමේරූ ක්ෂුද්‍ර ප්‍රශස්තිකරණය සියලු නපුරේ මුල වේ, මන්ද ක්ෂුද්‍ර ප්‍රශස්තිකරණය සන්දර්භයෙන් බැහැර වේ. ඔවුන් කිසි විටෙකත් තමන් බලාපොරොත්තු වන ආකාරයට හැසිරෙන්නේ නැත.

වැදගත් අනුපිළිවෙලෙහි හොඳ මුල් ප්‍රශස්තිකරණයන් මොනවාද:

• වාස්තු විද්‍යාත්මක ප්‍රශස්තිකරණය (යෙදුම් ව්‍යුහය, එය සංයුක්ත කර ඇති ආකාරය සහ ස්ථර කර ඇති ආකාරය)
• දත්ත ප්‍රවාහ ප්‍රශස්තිකරණය (යෙදුමේ ඇතුළත හා පිටත)

සමහර මධ්‍ය සංවර්ධන චක්‍ර ප්‍රශස්තිකරණය:

• දත්ත ව්‍යුහයන්, අවශ්‍ය නම් වඩා හොඳ කාර්ය සාධනයක් හෝ අඩු පොදු කාර්යයක් ඇති නව දත්ත ව්‍යුහයන් හඳුන්වා දෙන්න
• ඇල්ගොරිතම (ක්වික්සෝර්ට් 3 සහ හෙප්සෝර්ට් අතර තීරණය කිරීම ආරම්භ කිරීමට දැන් හොඳ කාලයකි ;-))

සමහර සංවර්ධන චක්‍ර ප්‍රශස්තිකරණයන් අවසන් කරයි

• කේත හොට්පොට් සොයා ගැනීම (තද ලූප, එය ප්‍රශස්තිකරණය කළ යුතුය)
• කේතයේ පරිගණකමය කොටස් පැතිකඩ පදනම් කරගත් ප්‍රශස්තිකරණය
• යෙදුමේ සන්දර්භය තුළ සිදු කර ඇති බැවින් ක්ෂුද්‍ර ප්‍රශස්තිකරණය දැන් කළ හැකි අතර ඒවායේ බලපෑම නිවැරදිව මැනිය හැකිය.

මුල් කාලීන ප්‍රශස්තිකරණයන් සියල්ලම නපුරු නොවේ, සංවර්ධන ජීවන චක්‍රයේ වැරදි වේලාවක සිදු කළ හොත් ක්ෂුද්‍ර ප්‍රශස්තිකරණය නපුරු ය , මන්ද ඒවා ගෘහ නිර්මාණ ශිල්පයට negative ණාත්මක ලෙස බලපානු ඇත, ආරම්භක tivity ලදායිතාවයට ly ණාත්මක ලෙස බලපෑම් කළ හැකිය, අදාළ නොවන කාර්ය සාධනය නැණවත් විය හැකිය හෝ අවසානයේ අහිතකර බලපෑමක් ඇති කළ හැකිය. විවිධ පාරිසරික තත්ත්වයන් හේතුවෙන් සංවර්ධනයේ.

කාර්ය සාධනය සැලකිලිමත් නම් (සහ සෑම විටම විය යුතුය) සෑම විටම විශාල ලෙස සිතන්න . කාර්ය සාධනය විශාල පින්තූරයක් වන අතර එය වැනි දේ ගැන නොවේ: මම int හෝ long භාවිතා කළ යුතුද ?. බොටම් අප් වෙනුවට කාර්ය සාධනය සමඟ වැඩ කරන විට ඉහළට පහළට යන්න .

පළමු මිනුම් නොමැතිව ප්‍රශස්තිකරණය සෑම විටම පාහේ නොමේරූ ය.

මෙම නඩුවේ එය සත්‍යයක් යැයි මම විශ්වාස කරමි.

එය හේතු වන්නේ නම් ප්‍රශස්තිකරණය “නපුර” වේ:

• අඩු පැහැදිලි කේතයක්
• සැලකිය යුතු ලෙස වැඩි කේතයක්
• අඩු ආරක්ෂිත කේතය
• ක්‍රමලේඛක කාලය නාස්ති කිරීම

ඔබගේ නඩුවේදී, ක්‍රමලේඛක කාලය දැනටමත් වැය කර ඇති බවක් පෙනේ, කේතය එතරම් සංකීර්ණ නොවීය (කණ්ඩායමේ සිටින සියල්ලන්ටම තේරුම් ගත හැකි වනු ඇතැයි ඔබේ අදහස් දැක්වීමේ අනුමානයකි), සහ කේතය තව ටිකක් අනාගත සාක්ෂි වේ (වීම) නූල් ආරක්ෂිතයි, මම ඔබේ විස්තරය තේරුම් ගත්තා නම්). ටිකක් නපුරක් වගේ. :)

මෙම ප්‍රශ්නය අවුරුදු 5 ක් පැරණි වීම ගැන මම පුදුම වෙමි, එහෙත් වාක්‍ය කිහිපයකට වඩා නුත්ට පැවසීමට ඇති දේ කිසිවෙකු පළ කර නැත. සුප්‍රසිද්ධ උපුටා දැක්වීම වටා ඇති ඡේද කිහිපයක් එය මනාව පැහැදිලි කරයි. උපුටා දක්වා ඇති පුවත්පත “ ප්‍රකාශන සමඟ ව්‍යුහගත ක්‍රමලේඛනය ” ලෙස හැඳින්වෙන අතර, එය අවුරුදු 40 කට ආසන්න වන අතර, මතභේදයක් සහ මෘදුකාංග ව්‍යාපාරයක් ගැන තවදුරටත් නොපවතින අතර බොහෝ දෙනෙකුට කවදාවත් නොතිබූ ක්‍රමලේඛන භාෂාවල උදාහරණ ඇත. අසා ඇති, පුදුම සහගත ලෙස එය පැවසූ දෙයින් තවමත් අදාළ වේ.

මෙන්න විශාල උපුටා දැක්වීමක් (පීඩීඑෆ් හි 8 වන පිටුවෙන්, මුල් පිටුවේ 268 පිටුව):

උදාහරණ 2 සිට උදාහරණ 2a දක්වා වේගය වැඩි දියුණු කිරීම 12% ක් පමණ වන අතර බොහෝ අය එය නොවැදගත් බව ප්‍රකාශ කරයි. අද බොහෝ මෘදුකාංග ඉංජිනේරුවන් විසින් බෙදාගෙන ඇති සාම්ප්‍රදායික ප්‍ර wisdom ාව කුඩා දේවල කාර්යක්ෂමතාව නොසලකා හැරිය යුතුය. නමුත් මෙය හුදෙක් ඔවුන්ගේ “ප්‍රශස්ත” වැඩසටහන් නිදොස් කිරීමට හෝ නඩත්තු කිරීමට නොහැකි, සතයක් හෝ රාත්තල්-මෝඩ ක්‍රමලේඛකයින් විසින් ක්‍රියාවට නංවන බව දකින අපයෝජනයන්ට අධික ලෙස ප්‍රතිචාරයක් යැයි මම විශ්වාස කරමි. ස්ථාපිත ඉංජිනේරු විෂයයන්හි 12% ක වර්ධනයක්, පහසුවෙන් ලබා ගත හැකි අතර එය කිසි විටෙකත් ආන්තික ලෙස නොසැලකේ. මෘදුකාංග ඉංජිනේරු විද්‍යාවේ ද එම මතයම පැවතිය යුතු යැයි මම විශ්වාස කරමි. ඇත්ත වශයෙන්ම මම එකවර වෙඩි තැබීමේ රැකියාවක් සඳහා එවැනි ප්‍රශස්තිකරණයන් කිරීමට කරදර නොවෙමි, නමුත් එය ගුණාත්මක වැඩසටහන් සකස් කිරීමේ ප්‍රශ්නයක් වන විට, එවැනි කාර්යක්ෂමතාවන් මට ප්‍රතික්ෂේප කරන මෙවලම් වලට පමණක් සීමා වීමට මට අවශ්‍ය නැත.

කාර්යක්ෂමතාවයේ ග්‍රේල් අපයෝජනයට තුඩු දෙන බවට සැකයක් නැත. ක්‍රමලේඛකයින් ඔවුන්ගේ වැඩසටහන් වල අවිධිමත් කොටස්වල වේගය ගැන සිතීමට හෝ කනස්සල්ලට පත්වීමට විශාල කාලයක් නාස්ති කරන අතර, කාර්යක්ෂමතාව සඳහා වන මෙම උත්සාහයන් නිදොස් කිරීම සහ නඩත්තු කිරීම සලකා බැලීමේදී සැබවින්ම ප්‍රබල negative ණාත්මක බලපෑමක් ඇති කරයි. කුඩා කාර්යක්ෂමතාවයන් ගැන අප අමතක කළ යුතුය , කාලය 97% ක් පමණ කියන්න: නොමේරූ ප්‍රශස්තකරණය සියලු නපුරේ මුල වේ.

එහෙත් එම තීරණාත්මක 3% තුළ අප අපගේ අවස්ථාවන් අත් නොහැරිය යුතුය. හොඳ ක්‍රමලේඛකයෙකු එවැනි තර්ක විතර්කවලින් උදාසීනභාවයට පත් නොවනු ඇත, විවේචනාත්මක කේතය දෙස හොඳින් බැලීමට ඔහු බුද්ධිමත් වනු ඇත; නමුත් එම කේතය හඳුනා ගැනීමෙන් පසුව පමණි. මිනුම් මෙවලම් භාවිතා කරන ක්‍රමලේඛකයින්ගේ විශ්වීය අත්දැකීම් වී ඇත්තේ ඔවුන්ගේ බුද්ධිමය අනුමාන අසාර්ථක වීම නිසා වැඩසටහනක කුමන කොටස් සැබවින්ම තීරණාත්මකද යන්න පිළිබඳව ප්‍රාථමික විනිශ්චයක් කිරීම බොහෝ විට වැරැද්දකි.

පෙර පිටුවෙන් තවත් හොඳ කොටසක්:

කාල වකවානු වල ප්‍රවණතා අනුව මගේම ක්‍රමලේඛන විලාසය ඇත්ත වශයෙන්ම පසුගිය දශකය තුළ වෙනස් වී ඇත (උදා: මම තවදුරටත් එතරම් ව්‍යාකූල නොවෙමි, මම යන්නට යන්නේ අඩුවෙන්), නමුත් මගේ ශෛලියේ විශාල වෙනසක් සිදුවී ඇත මෙම අභ්‍යන්තර ලූප සංසිද්ධියට. විවේචනාත්මක අභ්‍යන්තර පුඩුවක් තුළ ඇති සෑම මෙහෙයුමක් ගැනම මම දැන් අතිශයින්ම සෙංගමාලය දෙස බලා සිටිමි, මගේ වැඩසටහන සහ දත්ත ව්‍යුහය වෙනස් කිරීමට උත්සාහ කරමි (උදාහරණ 1 සිට උදාහරණ 2 දක්වා වෙනස් වූවාක් මෙන්) එවිට සමහර මෙහෙයුම් ඉවත් කළ හැකිය. මෙම ප්‍රවේශයට හේතු වනුයේ: අ) අභ්‍යන්තර පුඩුවක් කෙටි බැවින් වැඩි කාලයක් ගත නොවේ; ආ) ගෙවීම සැබෑ ය; සහ ඇ) එවිට මගේ වැඩසටහන් වල අනෙක් කොටස්වල අඩු කාර්යක්ෂමතාවයක් ඇති කර ගැනීමට මට හැකි වන අතර එම නිසා ඒවා වඩාත් කියවිය හැකි සහ පහසුවෙන් ලිවිය හැකි සහ නිදොස්කරණය කර ඇත.

මෙම උපුටා දැක්වීම පැහැදිලිවම නරක කේතයක් හෝ කේතයක් සාධාරණීකරණය කිරීම සඳහා භාවිතා කර ඇති බව මම බොහෝ විට දැක ඇත්තෙමි, එහි ක්‍රියාකාරිත්වය මනිනු නොලැබුවද, කේත ප්‍රමාණය වැඩි නොකර හෝ කියවීමේ හැකියාව අඩපණ නොකර බොහෝ විට ඉතා පහසුවෙන් කළ හැකිය.

පොදුවේ ගත් කල, මුල් ක්ෂුද්‍ර ප්‍රශස්තිකරණය නරක අදහසක් විය හැකි යැයි මම සිතමි. කෙසේ වෙතත්, සාර්ව ප්‍රශස්තිකරණය (O (N ^ 2) වෙනුවට O (log N) ඇල්ගොරිතමයක් තෝරා ගැනීම වැනි දේ බොහෝ විට වටී. එය O (N ^ 2) ඇල්ගොරිතමයක් ලිවීම නාස්තියක් විය හැකි බැවින් කල්තියාම කළ යුතුය. ඕ (ලොග් එන්) ප්‍රවේශයකට පක්ෂව එය සම්පූර්ණයෙන්ම විසි කරන්න.

වචන විය හැකි බව සලකන්න : O (N ^ 2) ඇල්ගොරිතම සරල හා ලිවීමට පහසු නම්, එය මන්දගාමී බව පෙනේ නම් ඔබට වරදකාරී හැඟීමකින් තොරව එය ඉවත දැමිය හැකිය. නමුත් ඇල්ගොරිතම දෙකම එක හා සමානව සංකීර්ණ නම්, හෝ අපේක්ෂිත කාර්ය භාරය විශාල නම් ඔබට වේගවත් එකක් අවශ්‍ය බව ඔබ දැනටමත් දන්නවා නම්, කලින් ප්‍රශස්තිකරණය කිරීම හොඳ ඉංජිනේරු තීරණයක් වන අතර එය දිගු කාලීනව ඔබගේ මුළු වැඩ ප්‍රමාණය අඩු කරනු ඇත.

මේ අනුව, පොදුවේ ගත් කල, මම සිතන්නේ නිවැරදි ප්‍රවේශය නම් ඔබ කේතය ලිවීමට පෙර ඔබේ විකල්ප මොනවාදැයි සොයා බැලීම සහ ඔබේ තත්වය සඳහා හොඳම ඇල්ගොරිතම දැනුවත්ව තෝරා ගැනීමයි. වැදගත්ම දෙය නම්, “නොමේරූ ප්‍රශස්තකරණය සියලු නපුරේ මුලයි” යන යෙදුම නොදැනුවත්කමට නිදහසට කරුණක් නොවේ. පොදු මෙහෙයුම් සඳහා කොපමණ මුදලක් වැය වේද යන්න පිළිබඳ සාමාන්‍ය අදහසක් වෘත්තීය සංවර්ධකයින්ට තිබිය යුතුය; ඔවුන් දැනගත යුතුයි, උදාහරණයක් ලෙස

• එම නූල් සංඛ්‍යාවට වඩා වැඩිය
• සංඛ්‍යාත්මකව ටයිප් කළ භාෂාවන්ට වඩා ගතික භාෂා මන්දගාමී බව
• සම්බන්ධිත ලැයිස්තු වලට වඩා අරාව / දෛශික ලැයිස්තු වල වාසි, සහ අනෙක් අතට
• හැෂ් ටේබල් භාවිතා කරන්නේ කවදාද, වර්ග කළ සිතියමක් භාවිතා කරන්නේ කවදාද, සහ ගොඩවල් භාවිතා කරන්නේ කවදාද
• (ඔවුන් ජංගම උපාංග සමඟ වැඩ කරන්නේ නම්) ඩෙස්ක්ටොප් පරිගණකවල "ද්විත්ව" සහ "ඉන්ට" සමාන ක්‍රියාකාරිත්වයක් ඇත (එෆ්පී ඊටත් වඩා වේගවත් විය හැක) නමුත් එෆ්පීයූ නොමැතිව අඩු මට්ටමේ ජංගම උපාංගවල "ද්විත්ව" සිය ගුණයකින් මන්දගාමී විය හැකිය;
• අන්තර්ජාලය හරහා දත්ත මාරු කිරීම HDD ප්‍රවේශයට වඩා මන්දගාමී වන අතර, HDDs RAM වලට වඩා බෙහෙවින් මන්දගාමී වේ, RAM L1 හැඹිලි සහ රෙජිස්ටාර් වලට වඩා මන්දගාමී වේ, සහ අන්තර්ජාල මෙහෙයුම් දින නියමයක් නොමැතිව අවහිර විය හැකිය (සහ ඕනෑම වේලාවක අසාර්ථක වේ).

සංවර්ධකයින්ට දත්ත ව්‍යුහයන් සහ ඇල්ගොරිතම පිළිබඳ මෙවලම් පෙට්ටියක් හුරුපුරුදු විය යුතු අතර එමඟින් ඔවුන්ට කාර්යය සඳහා නිවැරදි මෙවලම් පහසුවෙන් භාවිතා කළ හැකිය.

ඕනෑ තරම් දැනුම සහ පුද්ගලික මෙවලම් පෙට්ටියක් තිබීම ඔබට පහසුවෙන් උත්සාහ කළ හැකිය. අනවශ්ය විය හැකි බව මතු කර දැක්වීම බවට විශාල වෙහෙසක් දමා ඇත (සහ මම වරක් වඩා වැඩි බව උගුළට වැටීමෙන් පිළිගන්න) නපුර. නමුත් ප්‍රශස්තිකරණය අරාව වෙනුවට කට්ටලයක් / හැෂ් ටේබල් එකක් තෝරා ගැනීම හෝ නූල් [] වෙනුවට ද්විත්ව [] සංඛ්‍යා ලැයිස්තුවක් ගබඩා කිරීම තරම් පහසු වන විට , එසේ නොවන්නේ මන්ද? මම මෙහි නුත් සමඟ එකඟ නොවිය හැකිය, මට විශ්වාස නැත, නමුත් මම හිතන්නේ ඔහු කතා කළේ පහත් මට්ටමේ ප්‍රශස්තිකරණය ගැන වන අතර මම කතා කරන්නේ ඉහළ මට්ටමේ ප්‍රශස්තිකරණය ගැන ය.

මතක තබා ගන්න, එම උපුටා ගැනීම මුලින් 1974 සිට ය. 1974 දී පරිගණක මන්දගාමී වූ අතර පරිගණක බලය මිල අධික විය. මම හිතන්නේ ඒක තමයි නුත්ට විරුද්ධ වුණේ. ඔහු "කාර්ය සාධනය ගැන කිසිසේත් කරදර නොවන්න" යැයි නොකියයි, මන්ද 1974 දී එය පිස්සු කතාවක් වනු ඇත. නුත් පැහැදිලි කළේ ප්‍රශස්තිකරණය කරන්නේ කෙසේද යන්නයි ; කෙටියෙන් කිවහොත්, යමෙකු අවධානය යොමු කළ යුත්තේ බාධක කෙරෙහි පමණක් වන අතර, එසේ කිරීමට පෙර ඔබ බාධක සොයා ගැනීම සඳහා මිනුම් සිදු කළ යුතුය.

ඔබ මැනීමට වැඩසටහනක් ලියන තුරු ඔබට බාධක සොයාගත නොහැකි බව සලකන්න, එයින් අදහස් කරන්නේ මැනීමට කිසිවක් පැවතීමට පෙර සමහර කාර්ය සාධන තීරණ ගත යුතු බවයි. සමහර විට මෙම තීරණ ඔබ වැරදියි නම් වෙනස් කිරීම අපහසු වේ. මේ හේතුව නිසා, දෘඩ දත්ත නොමැති විට සාධාරණ තීරණ ගැනීමට ඔබට හැකි වන දේ සඳහා පොදු අදහසක් තිබීම හොඳය.

ප්‍රශස්තිකරණය කිරීමට කොතරම් ඉක්මනින්ද, සහ කාර්ය සාධනය ගැන කොපමණ කරදර විය යුතුද යන්න රැකියාව මත රඳා පවතී. ඔබ කිහිප වතාවක් පමණක් ධාවනය වන ස්ක්‍රිප්ට් ලිවීමේදී, කාර්ය සාධනය ගැන කරදර වීම සාමාන්‍යයෙන් සම්පූර්ණ කාලය නාස්තියකි. නමුත් ඔබ මයික්‍රොසොෆ්ට් හෝ ඔරකල් සඳහා වැඩ කරන්නේ නම් සහ ඔබ වෙනත් සංවර්ධකයින් දහස් ගණනක් විවිධ ආකාරවලින් භාවිතා කිරීමට යන පුස්තකාලයක වැඩ කරන්නේ නම් , එයින් නිරය ප්‍රශස්ත කිරීම සඳහා ගෙවිය හැකිය, එවිට ඔබට විවිධත්වය ආවරණය කළ හැකිය නඩු කාර්යක්ෂමව භාවිතා කරන්න. එසේ වුවද, කාර්ය සාධනයේ අවශ්‍යතාවය සෑම විටම කියවීමේ හැකියාව, නඩත්තු කිරීමේ හැකියාව, අලංකාරය, විස්තීරණතාව සහ යනාදිය සමඟ සමතුලිත විය යුතුය.

පුද්ගලිකව, පෙර ත්‍රෙඩ් එකක ආවරණය කර ඇති පරිදි , ඔබ කාර්ය සාධන ගැටළු වලට මුහුණ දෙන බව ඔබ දන්නා අවස්ථාවන්හිදී මුල් ප්‍රශස්තිකරණය නරක යැයි මම විශ්වාස නොකරමි. උදාහරණයක් ලෙස, මම පෘෂ් model ීය ආකෘති නිර්මාණය සහ විශ්ලේෂණ මෘදුකාංග ලියමි, එහිදී මම නිරන්තරයෙන් මිලියන ගණනක් ආයතන සමඟ ගනුදෙනු කරමි. සැලසුම් අවධියේදී ප්‍රශස්ත කාර්ය සාධනය සඳහා සැලසුම් කිරීම දුර්වල මෝස්තරයක ප්‍රමාද ප්‍රශස්තිකරණයට වඩා බෙහෙවින් උසස් ය.

සලකා බැලිය යුතු තවත් දෙයක් නම් අනාගතයේදී ඔබගේ යෙදුම පරිමාණය කරන්නේ කෙසේද යන්නයි. ඔබේ කේතයට දීර් life ායුෂ ඇති බව ඔබ සලකන්නේ නම්, සැලසුම් අවධියේදී කාර්ය සාධනය ප්‍රශස්ත කිරීමද හොඳ අදහසකි.

මගේ අත්දැකීම් අනුව, ප්‍රමාද වූ ප්‍රශස්තිකරණය ඉහළ මිලකට සොච්චම් ප්‍රතිලාභ ලබා දෙයි. සැලසුම් අවධියේදී ප්‍රශස්තිකරණය කිරීම, ඇල්ගොරිතම තේරීම සහ කරකැවීම හරහා වඩා හොඳය. ඔබේ කේතය ක්‍රියා කරන ආකාරය තේරුම් ගැනීමට පැතිකඩක් මත පදනම්ව ඉහළ කාර්යසාධන කේතයක් ලබා ගැනීමට හොඳ ක්‍රමයක් නොවේ, ඔබ මෙය කලින් දැන සිටිය යුතුය.

නොමේරූ ප්‍රශස්තකරණය බොහෝ විට සියලු නපුරේ මුල බව මම ඉගෙන ගතිමි.

මිනිසුන් මෘදුකාංග ලියන විට මුලදී අස්ථාවරත්වය, සීමිත විශේෂාංග, නරක භාවිතාව සහ නරක ක්‍රියාකාරිත්වය වැනි ගැටළු ඇති වේ. මෘදුකාංගය පරිණත වූ විට මේ සියල්ල සාමාන්‍යයෙන් ස්ථාවර වේ.

කාර්ය සාධනය හැර මේ සියල්ල. කිසිවෙකු කාර්ය සාධනය ගැන සැලකිලිමත් වන බවක් නොපෙනේ. හේතුව සරලයි: මෘදුකාංගයක් බිඳ වැටුනහොත්, යමෙකු දෝෂය නිවැරදි කරනු ඇති අතර, එය අංගයක් අස්ථානගත වී ඇත්නම්, යමෙකු එය ක්‍රියාත්මක කර සිදු කරනු ඇත, මෘදුකාංගයේ නරක ක්‍රියාකාරීත්වයක් තිබේ නම් එය බොහෝ විට සිදුවන්නේ මයික්‍රොපයිටිමේෂන් නැතිවීම නිසා නොවේ, නමුත් නරක නිර්මාණය හේතුවෙන් කිසිවෙකු මෘදුකාංගයේ සැලසුම ස්පර්ශ නොකරනු ඇත. කවදාවත්.

බොක්ස් දෙස බලන්න. එය අපායක් මෙන් මන්දගාමී ය. එය කවදා හෝ වේගවත් වේද? සමහර විට, නමුත් සියයට කිහිපයක පරාසයක පමණි. VMWare හෝ VBox හෝ QEMU වැනි අථත්‍යකරණ මෘදුකාංග සමඟ සැසඳිය හැකි කාර්ය සාධනයක් එය කිසි විටෙකත් ලබා නොගනී. එය සැලසුම අනුව මන්දගාමී නිසා!

මෘදුකාංගයක ගැටළුව එය මන්දගාමී නම්, එය ඉතා මන්දගාමී වන නිසා සහ මෙය නිවැරදි කළ හැක්කේ බහුතරයකගේ ක්‍රියාකාරිත්වය වැඩි දියුණු කිරීමෙන් පමණි. + 10% හුදෙක් මන්දගාමී මෘදුකාංගයක් වේගවත් නොකරනු ඇත. පසුකාලීන ප්‍රශස්තිකරණයෙන් ඔබට සාමාන්‍යයෙන් 10% ට වඩා ලැබෙන්නේ නැත.

එබැවින් ඔබේ මෘදුකාංගයට කාර්ය සාධනය කිසියම් වැදගත්කමක් තිබේ නම්, එය සැලසුම් කිරීමේදී ආරම්භයේ සිටම ඔබ එය සැලකිල්ලට ගත යුතුය, "අනේ ඔව්, එය මන්දගාමී ය, නමුත් අපට එය පසුව වැඩි දියුණු කළ හැකිය". ඔබට නොහැකි නිසා!

එය ඔබගේ නිශ්චිත සිද්ධියට නොගැලපෙන බව මම දනිමි, නමුත් එය "නොමේරූ ප්‍රශස්තකරණය සැබවින්ම සියලු නපුරේ මුලද?" - පැහැදිලි අංකයකින්.

ඕනෑම අංගයක් වැනි සෑම ප්‍රශස්තිකරණයක්ම ප්‍රවේශමෙන් සැලසුම් කර ක්‍රියාත්මක කළ යුතුය. පිරිවැය සහ ප්‍රතිලාභ පිළිබඳ නිසි ඇගයීමක් ඊට ඇතුළත් ය. මැනිය හැකි කාර්ය සාධන වාසියක් නිර්මාණය නොකරන විට, මෙහි සහ එහි චක්‍ර කිහිපයක් සුරැකීමට ඇල්ගොරිතමයක් ප්‍රශස්තිකරණය නොකරන්න.

නිදසුනක් ලෙස: ශ්‍රිතයක් ඉන්ලයින් කිරීමෙන් ඔබට එය වැඩිදියුණු කළ හැකිය, සමහර විට චක්‍ර අතළොස්සක් ඉතිරි කර ගත හැකිය, නමුත් ඒ සමඟම ඔබ ඔබේ ක්‍රියාත්මක කළ හැකි ප්‍රමාණය වැඩි කර, ටීඑල්බී සහ හැඹිලි මග හැරීමේ අවස්ථා වැඩි කරමින් දහස් ගණනක් චක්‍ර හෝ පිරිවැය පේජිං මෙහෙයුම්, එමඟින් කාර්ය සාධනය මුළුමනින්ම විනාශ වේ. ඔබට මේ දේවල් තේරෙන්නේ නැත්නම්, ඔබේ “ප්‍රශස්තිකරණය” නරක විය හැකිය.

මෝඩ ප්‍රශස්තිකරණය "නොමේරූ" ප්‍රශස්තිකරණයට වඩා නපුරකි, නමුත් දෙකම තවමත් නොමේරූ ප්‍රශස්තිකරණයට වඩා හොඳය.

තැ.කා.සි. සමඟ ගැටලු දෙකක් තිබේ: පළමුව, අත්‍යවශ්‍ය නොවන වැඩ සඳහා සංවර්ධන කාලය භාවිතා කිරීම, වැඩි විශේෂාංග ලිවීමට හෝ තවත් දෝෂ නිවැරදි කිරීමට භාවිතා කළ හැකි අතර, දෙවනුව, කේතය කාර්යක්ෂමව ක්‍රියාත්මක වන බවට ව්‍යාජ ආරක්‍ෂාව පිළිබඳ හැඟීම. තැ.කා.සි. බොහෝ විට සම්බන්ධ වන්නේ බෝතල්-බෙල්ල නොවන කේත ප්‍රශස්තිකරණය කිරීම වන අතර, එම කේතය නොදැන සිටීම. “නොමේරූ” බිට් යන්නෙන් අදහස් කරන්නේ නිසි මිනුම් භාවිතයෙන් ගැටලුවක් හඳුනා ගැනීමට පෙර ප්‍රශස්තිකරණය සිදු කිරීමයි.

එබැවින් මූලික වශයෙන්, ඔව්, මෙය නොමේරූ ප්‍රශස්තිකරණයක් සේ පෙනේ, නමුත් එය දෝෂ හඳුන්වා දෙන්නේ නම් මිස මම එය පසුබසින්නේ නැත - සියල්ලට පසු, එය දැන් ප්‍රශස්තිකරණය කර ඇත (!)

මම විශ්වාස කරන්නේ එය මයික් කෝන් 'රන් ආලේපනය' කේතය ලෙස හඳුන්වන බවයි - එනම් හොඳ විය හැකි නමුත් අවශ්‍ය නොවන දේවල් සඳහා කාලය ගත කිරීමයි.

ඔහු ඊට එරෙහිව උපදෙස් දුන්නේය.

PS 'රන් ආලේපනය' සීනුව හා විස්ල් ආකාරයේ ක්‍රියාකාරීත්වය පිරිවිතර අනුව විය හැකිය. ඔබ කේතය දෙස බලන විට එය අනවශ්‍ය ප්‍රශස්තිකරණය, 'අනාගත-සහතික කළ' පන්ති ආදිය ගනී.

කේතය තේරුම් ගැනීමේ කිසිදු ගැටළුවක් නොමැති බැවින් මෙම නඩුව ව්‍යතිරේකයක් ලෙස සැලකිය හැකිය.

නමුත් පොදුවේ ප්‍රශස්තිකරණය අඩු කියවිය හැකි සහ තේරුම්ගත නොහැකි කේතයකට මඟ පෙන්වන අතර එය යෙදිය යුත්තේ අවශ්‍ය විටෙක පමණි. සරල උදාහරණයක් - ඔබට මූලද්‍රව්‍ය කිහිපයක් පමණක් වර්ග කළ යුතු බව ඔබ දන්නේ නම් - බබල්සෝර්ට් භාවිතා කරන්න. නමුත් මූලද්‍රව්‍ය වැඩි විය හැකි යැයි ඔබ සැක කරන්නේ නම් සහ ඔබ කොපමණ දැයි නොදන්නේ නම්, ක්වික්සෝර්ට් සමඟ ප්‍රශස්තිකරණය කිරීම (උදාහරණයක් ලෙස) නපුරක් නොව අත්‍යවශ්‍ය කරුණකි. වැඩසටහන සැලසුම් කිරීමේදී මෙය සලකා බැලිය යුතුය.

නොමේරූ ප්‍රශස්තිකරණය පිළිබඳ ගැටළුව බොහෝ දුරට සිදුවන්නේ පවතින කේතය වේගවත් ලෙස නැවත ලිවීමේදී බව මම සොයාගෙන ඇත. මුලින් ම යම් කැටි ගැසුණු ප්‍රශස්තිකරණයක් ලිවීම ගැටළුවක් වන්නේ කෙසේදැයි මට පෙනේ, නමුත් බොහෝ විට මම දකින්නේ නොමේරූ ප්‍රශස්තිකරණය කැඩී නැති දෙය නිවැරදි කිරීමේදී එහි අවලස්සන හිස ඇති කර ගැනීමයි.

මෙහි ඇති නරකම උදාහරණය වන්නේ සම්මත පුස්තකාලයකින් යමෙකු අංගයන් නැවත ක්‍රියාත්මක කරන ආකාරය මා දකින සෑම අවස්ථාවකම ය. එය ප්‍රධාන රතු ධජයකි. හරියට, මම වරක් දුටුවා යමෙකු නූල් හැසිරවීම සඳහා අභිරුචි පිළිවෙත් ක්‍රියාත්මක කරන බව.

මෙහි ප්‍රති results ලය වන්නේ තේරුම් ගැනීමට අපහසු (නරක) කේතයක් වන අතර බොහෝ විට ප්‍රයෝජනවත් නොවන (නරක) වැඩ සඳහා වැඩි කාලයක් ගත කිරීමයි.

වෙනස් දෘෂ්ටිකෝණයකින් බලන විට, බොහෝ ක්‍රමලේඛකයින් / සංවර්ධකයින් සාර්ථකත්වය සඳහා සැලසුම් නොකරන අතර "මූලාකෘතිය" සෑම විටම පාහේ මුදාහැරීම 1.0 බවට පත්වේ. ක්ලැසික්, සරාගී සහ ඉහළ ක්‍රියාකාරී ඉදිරිපස (මූලික වශයෙන් යූඅයි) පුළුල් ලෙස ව්‍යාප්ත වූ පරිශීලක දරුකමට හදා ගැනීම සහ උද්යෝගය ඇති කළ වෙනම මුල් නිෂ්පාදන 4 ක් සමඟ මට පළමු අත්දැකීම් තිබේ. මෙම සෑම නිෂ්පාදනයක් තුළම, කාර්ය සාධන ගැටළු සාපේක්ෂව කෙටි කාලයක් තුළ (අවුරුදු 1 සිට 2 දක්වා) විශේෂයෙන් විශාල, වැඩි ඉල්ලුමක් ඇති ගනුදෙනුකරුවන් විසින් නිෂ්පාදිතය භාවිතා කිරීමට පටන් ගත්හ. කළමනාකරණයේ ප්‍රමුඛතා ලැයිස්තුවේ නව අංග සංවර්ධනය ආධිපත්‍යය දැරුවත් ඉතා ඉක්මණින් කාර්ය සාධනය ගැටළු ලැයිස්තුවේ ආධිපත්‍යය දැරීය. සෑම නිකුතුවක්ම නව විශේෂාංග එකතු කළ නිසා ගනුදෙනුකරුවන් වඩ වඩාත් කලකිරීමට පත් වූ අතර ඒවා කාර්ය සාධනයේ ගැටළු හේතුවෙන් ප්‍රවේශ විය නොහැකි විය.

එබැවින්, "ප්‍රෝටෝ-වර්ගයේ" එතරම් සැලකිල්ලක් නොදක්වන ඉතා මූලික සැලසුම් සහ ක්‍රියාත්මක කිරීමේ අඩුපාඩු නිෂ්පාදනවල (සහ සමාගම්වල) දිගුකාලීන සාර්ථකත්වයට විශාල බාධාවක් විය.

ඔබේ ගනුදෙනුකරුවන්ගේ නිරූපණය ඔබේ ලැප්ටොප් පරිගණකයේ XML DOMs, SQL එක්ස්ප්‍රස් සහ බොහෝ සේවාදායක පාර්ශවයේ හැඹිලි දත්ත සමඟ විශිෂ්ට ලෙස ක්‍රියා කරයි. ඔබ සාර්ථක නම් නිෂ්පාදන පද්ධතිය පිළිස්සීමක් ඇති කරයි.

1976 දී අපි තවමත් වර්ග මූලයක් ගණනය කිරීමේ හෝ විශාල අරාවක් වර්ග කිරීමේ ප්‍රශස්ත ක්‍රම පිළිබඳව විවාද කරමින් සිටියෙමු. දොන් නූත්ගේ කියමන යොමු වූයේ ගැටළුව විසඳීම කෙරෙහි අවධානය යොමු කරනවාට වඩා සැලසුම් ක්‍රියාවලියේ මුල් අවධියේදී එවැනි පහත් මට්ටමේ ක්‍රියාකාරකම් ප්‍රශස්ත කිරීම කෙරෙහි අවධානය යොමු කිරීමේ වැරැද්දට ය. ඉන්පසු කේතයේ දේශීයකරණය කළ ප්‍රදේශ ප්‍රශස්තිකරණය කිරීම.

කාර්යක්ෂම කේතයක් ලිවීම (සී ++, වීබී, ටී-එස්කියුඑල් හෝ වෙනත් ආකාරයකින්), හෝ දත්ත ගබඩාව නිසියාකාරව සැලසුම් නොකිරීම හෝ ශුද්ධ වැඩ ගෘහ නිර්මාණ ශිල්පය ගැන නොසැලකිලිමත් වීම සඳහා යමෙකු නිදහසට කරුණක් ලෙස පුනරාවර්තනය කරන විට, IMO ඔවුන් නිරූපණය කරන්නේ අපගේ කාර්යයේ සැබෑ ස්වභාවය පිළිබඳ ඉතා නොගැඹුරු අවබෝධයක්. රේ

එය "නොමේරූ" යන්න ඔබ අර්ථ දක්වන ආකාරය මත රඳා පවතී යැයි සිතමි. ඔබ ලියන විට පහත් මට්ටමේ ක්‍රියාකාරිත්වය ඉක්මන් කිරීම සහජයෙන්ම නපුරක් නොවේ. මම හිතන්නේ එය උපුටා දැක්වීමේ වරදවා වටහා ගැනීමකි. සමහර විට මම සිතන්නේ එම උපුටා දැක්වීම තවත් සුදුසුකම් සමඟ කළ හැකි බවයි. කියවීමේ හැකියාව ගැන මම m_p ග්ලැඩියේටර්ගේ අදහස් ප්‍රතිරාවය කරමි.

පිළිතුර: එය රඳා පවතී. සංකීර්ණ දත්ත සමුදා විමසීම් වැනි ඇතැම් ආකාරයේ වැඩ සඳහා කාර්යක්ෂමතාව විශාල ගනුදෙනුවක් බව මම තර්ක කරමි. වෙනත් බොහෝ අවස්ථාවන්හිදී පරිගණකය වැඩි කාලයක් ගත කරන්නේ පරිශීලක ආදානය බලාපොරොත්තුවෙන් වන බැවින් බොහෝ කේත ප්‍රශස්තිකරණය කිරීම උපරිම උත්සාහයක් හා නරකම ප්‍රති p ලදායක වේ.

සමහර අවස්ථාවලදී ඔබට කාර්යක්ෂමතාව හෝ ක්‍රියාකාරිත්වය සඳහා සැලසුම් කළ හැකිය (වටහාගත් හෝ සැබෑ) - සුදුසු ඇල්ගොරිතමයක් තෝරා ගැනීම හෝ පරිශීලක අතුරුමුහුණතක් සැලසුම් කිරීම නිසා සමහර මිල අධික මෙහෙයුම් උදාහරණ ලෙස පසුබිමේ සිදු වේ. බොහෝ අවස්ථාවන්හීදී, උණුසුම් ස්ථාන තීරණය කිරීම සඳහා පැතිකඩ හෝ වෙනත් මෙහෙයුම් මඟින් ඔබට 10/90 ප්‍රතිලාභයක් ලැබෙනු ඇත.

මට විස්තර කළ හැකි එක් උදාහරණයක් නම්, උසාවි නඩු කළමනාකරණ පද්ධතියක් සඳහා මා වරක් කළ දත්ත ආකෘතිය එහි වගු 560 ක් පමණ තිබීමයි. එය සාමාන්‍යකරණයෙන් ආරම්භ විය (එක්තරා විශාල -5 සමාගමක උපදේශකවරයා පැවසූ පරිදි 'ලස්සනට සාමාන්‍යකරණය' කර ඇති අතර) අපට සිදුවිය යුතුව තිබුණේ අවලංගු කරන ලද දත්ත අයිතම හතරක් පමණි:

• සෙවුම් තිරයකට සහය දැක්වීම සඳහා ද්‍රව්‍යමය දර්ශනයක්

• ද්‍රව්‍යමය දෘෂ්ටියකින් කළ නොහැකි තවත් සෙවුම් තිරයකට සහය දැක්වීම සඳහා එක් ප්‍රේරක නඩත්තු කළ වගුවක්.

• අවලංගු කරන ලද එක් වාර්තාකරණ වගුවක් (මෙය පැවතියේ දත්ත ගබඩා ව්‍යාපෘතියක් ටින් කළ විට අපට යම් ප්‍රතිදාන වාර්තා ලබා ගැනීමට සිදු වූ බැවිනි)

• පද්ධතිය තුළ ඇති අසමාන සිදුවීම් විශාල සංඛ්‍යාවක නවතම දේ සෙවීමට සිදු වූ අතුරු මුහුණතක් සඳහා එක් ප්‍රේරක නඩත්තු කළ වගුවක්.

මෙය (එවකට) ඔස්ට්‍රේලියා හි විශාලතම J2EE ව්‍යාපෘතිය වන අතර එය වසර 100 කට වඩා වැඩි සංවර්ධක කාලයකි - තවද එය දත්ත සමුදා ක්‍රමවේදය තුළ අවලංගු කරන ලද අයිතම 4 ක් ඇති අතර ඉන් එකක් ඇත්ත වශයෙන්ම එහි කිසිසේත් අයත් නොවේ.

නොමේරූ ප්‍රශස්තිකරණය සියලු නපුරේ මුල නොවේ, එය නිසැකවම. කෙසේ වෙතත් එහි අඩුපාඩු තිබේ:

• ඔබ සංවර්ධන කාලය තුළ වැඩි කාලයක් ආයෝජනය කරයි
• ඔබ එය පරීක්ෂා කිරීමට වැඩි කාලයක් ආයෝජනය කරයි
• දෝෂ නිවැරදි කිරීමට ඔබ වැඩි කාලයක් ආයෝජනය කරයි

නොමේරූ ප්‍රශස්තිකරණය වෙනුවට, වඩා හොඳ ප්‍රශස්තිකරණය සඳහා සැබෑ අවශ්‍යතාවයක් තිබේදැයි බැලීමට යමෙකුට කලින් දෘශ්‍යතා පරීක්ෂණ කළ හැකිය.

"පීඑම්ඕ" (අර්ධ උපුටා දැක්වීම, එනම්) පිළිපදින බොහෝ දෙනා පවසන්නේ ප්‍රශස්තිකරණය මිනුම් මත පදනම් විය යුතු අතර මිනුම් අවසානය දක්වා සිදු කළ නොහැකි බවයි.

සංවර්ධනය අවසන් වීමට ආසන්නව තිබියදී කාර්ය සාධන පරීක්ෂණ අවසානයේදී සිදු කරනු ලබන බව විශාල පද්ධති සංවර්ධනයේ මගේ අත්දැකීමයි.

අප මෙම පුද්ගලයින්ගේ “උපදෙස්” අනුගමනය කරන්නේ නම්, සියලු පද්ධති ඉතා මන්දගාමී වනු ඇත. ඒවායේ දෘඩාංග අවශ්‍යතා මුලින් සිතුවාට වඩා විශාල බැවින් ඒවා මිල අධික වනු ඇත.

සංවර්ධන ක්‍රියාවලියේදී නියමිත වේලාවට කාර්ය සාධන පරීක්ෂණ සිදුකිරීමට මම දිගු කලක් තිස්සේ යෝජනා කර ඇත්තෙමි: එය නව කේතයක් තිබීම (මීට පෙර කිසිවක් නොතිබූ තැන) සහ පවතින කේතයේ තත්වය යන දෙකම පෙන්නුම් කරයි.

• අලුතින් ක්‍රියාත්මක කරන ලද කේතයේ ක්‍රියාකාරීත්වය පවත්නා සමාන කේත සමඟ සැසඳිය හැකිය. කාලයත් සමඟ නව කේතයේ ක්‍රියාකාරිත්වය සඳහා “හැඟීමක්” ඇති වේ.
• පවතින කේතය හදිසියේම පිදුරු ගසන්නේ නම්, ඔබට යම් දෙයක් සිදුවී ඇති බව ඔබට වැටහී ඇති අතර ඔබට එය වහාම විමර්ශනය කළ හැකිය, නමුත් (බොහෝ විට) එය සමස්ත පද්ධතියට බලපාන විට නොවේ.

තවත් සුරතල් අදහසක් වන්නේ ශ්‍රිත වාරණ මට්ටමින් මෘදුකාංග උපකරණ කිරීමයි. පද්ධතිය ක්‍රියාත්මක වන විට එය ක්‍රියාකාරී කොටස් සඳහා ක්‍රියාත්මක වන වේලාවන් පිළිබඳ තොරතුරු රැස් කරයි. පද්ධති උත්ශ්‍රේණිගත කිරීමක් සිදු කළ විට, කලින් නිකුත් කළ අවස්ථාවේ දී මෙන් ඒවා පිරිහී ඇති ශ්‍රිත කොටස් මොනවාද යන්න තීරණය කළ හැකිය. මෘදුකාංග තිරයක කාර්ය සාධන දත්ත උදව් මෙනුවෙන් ලබා ගත හැකිය.

PMO හි අර්ථය කුමක් විය හැකිද යන්න පිළිබඳව මෙම විශිෂ්ට කොටස බලන්න .