Kā noskaidrot, kur paliek laiks?

Virsraksts ir ļoti filozofisks, bet tai pašā laikā ļoti saistīts ar datubāzēm un programmēšanu kā tādu. Ikviens no programmētājiem ir saskāries ar problēmu, ka kods izpildās lēnāk nekā iecerēts vai katrā ziņā vismaz klientam tā šķiet. Tajā brīdī katrs no mums pielieto sev mīļākās metodes ko nu darīt. Daži tūlīt metas pie darba devēja vai klienta un sāk runāt par niknāka dzelža iegādi, daži drudžaini mēģina uzlabot tur kaut ko un šeit kaut ko, ja cilvēks ir veiksmīgs, iespējams tas viņam pat izdodas.
Diemžēl ne visi dzīvē ir veiksminieki un ne visi dzīvē ir tik pieredzējuši, lai ar savu intuīciju vai iepriekšējo pieredzi spētu izdomāt, kur tad šis laiks paliek. Un šajā gadījumā nekas cits neatliek kā izveidot precīzu atskaiti, kur tad laiks tiek pavadīts.
Ja es dzīvoju Jūrmalā (gribētos jau nu gan, bet patiesībā nekā:(), braucu ar mašīnu uz darbu Rīgā un katru rītu ierodos darbā par vēlu, tad ko man darīt? Tīri intuitīvi ko mēs darām? Pareizi – skriešus veicam pēdējos metrus no stāvvietas līdz darbam. Vai tiešām tam ir kāda jēga? Nu neapšaubāmi tam ir sportiska jēga un iespējams arī emocionāla jēga, kad priekšnieks redz, cik ļoti padotais vēlas strādāt. Taču attiecībā pret mūsu galveno mērķi – ierasties darbā ātrāk – jēga ir ļoti maza. Kāpēc? Tāpēc, ka sadalot pa sastāvdaļām mūsu maršruts izskatās apmēram šādi:

• 5 minūtes, lai no Jūrmalas tiktu ārā;
• 10 minūtes no Jūrmalas robežas līdz pirmajiem sastrēgumiem Rīgā;
• 30 minūtes, lai tiktu pāri tiltam līdz darbam;
• 2 minūtes, lai no stāvvietas uzkāptu pa trepēm un ienāktu birojā.

Pat, ja mēs iemācītos teleportēties no stāvvietas līdz birojam, tas kopējo laiku 47 minūtes samazinātu līdz 45 minūtēm un ietaupījums būtu ~4%. Diez ko iepriecinoši vis neizskatās.
Jūs teiksiet muļķīgi darām, vai ne? Jāminimizē kaut kā tie lielākie laika posmi!
Piemēram, varētu sākt ar 30 minūšu tupēšanu sastrēgumos. Kādas ir iespējas?

• Izbraukt ātrāk?
• Izbraukt vēlāk un sarunāt ar priekšnieku, ka mainam darba dienas sākumu un beigas?

Varbūt kļūt radošākiem un “domāt ārpus kastes” (think out of the box)? Piemēram:

• Iegādāties helikopteru?
• Mainīt darbu?
• Mainīt dzīvesvietu?
• Kļūt par rantjē?

Tieši tas pats attiecas arī uz standarta problēmu, kad programma strādā lēni. Nav haotiski un drudžaini jācenšas veikt kaut kādas maģiskas darbības, kuras palīdzēja Jānim pagājušogad un Pēterim vēl nupat nesen. Nav vērts savas pūles ieguldīt līdz neprātam skaņojot lielu SQL teikumu, kurš izpildās vienreiz un aizņem 5% no kopējā izpildes laika, bet tajā pašā laikā ir viens it kā sīks un necils SQL teikums, kas ciklā izpildās 10 tūkštoš reižu un aizņem 95% laika. Ir vienkārši jānoskaidro, kur laiks tiek patērēts. Jāsastāda atskaite ar darbībām, kas tiek veiktas pēc pogas nospiešanas un katrai šai darbībai jānomēra tās izpildes laiks. Un tad, kad ir skaidrs, kas bremzē un kas aizņem lielāko daļu laika, ir jāķeras pie šīs bremzes novēršanas.
Tikai tad jūs beidzot sapratīsiet, ko patiesībā jūs kods dara 🙂 Tikai tad jūs beidzot sapratīsiet kāda funkcionalitāte vispār zem šīs pogas slēpjas. Tikai tad jūs beidzot droši un precīzi varēsiet pateikt, lai beidz visās nelaimēs vainot Kanādu t.i. datu bāzi, vai arī tieši otrādi ķerties pie sliktā SQL teikuma vai procedūras (kas noteikti ir jāanalizē ar tādu pašu metodi tālāk) uzlabošanas/pārrakstīšanas/izmešanas.
Kādā veidā izveidot atskaiti, kurā parādās izpildītie soļi un to patērētais laiks, kā arī kādā veidā tad mēģināt panākt, lai konkrētā bremze nebūtu tik bremzīga, tas jau nav vairs šī raksta uzdevums.