O'ylab qarasam shuni o'zi yetar ekan qolgani bekor vaqtni sarflash. Oldin servisimiz manashu holda qanaqadir tupiklargacha borvosin. Da 700MB memory usage ko'p edi bazi runtime flaglar va kichik accumlationlarni yoqotib ko'rdim shular yetarli.

Servis o'zi shunchai notitifaction getway holos uyoqda asosiy narsa IO latency boshqa hechvaqo emas. Yani yog'liq narsani o'zi yo'q edi.

Bahonada kecha haskellda optimization haqida sal tayinli research qildim. Haskell runtime va GC haqida o'qidim, o'zi bu mavzular juda katta sekin sekin manashunaqa expirementlar doirasida ancha narsa o'rganib qo'ysa bo'ladi. Optimizatsiyalarga juda mukkasidan ketmaganman ammo o'ziga yarasha qiziq chunki Garbage collectorli til uchun bunaqa natijalar juda yoqimli. Haskellda corectess va perfomance juda balanced.

Endi keyingi qadamlar asosan biror narsalarni tezroq yakunlashga qaratilgan bo'lsa zo'r.

Yaqinda bir do'stim prikol qilgandi.

Tassavur qiling buyoqda kimdir ficha qanaqa bo'lishi kerakligini aytib turibti, siz esa eshitib yozyabsiz.

... manashunaqa narsalar bo'lishi kerak, qachon tayyor bo'ladi ?

— Aytilgan gaplarni tiplarga o'girib, servantda apilarni shaqillatib tashlaysiz va... Uje tayyor bo'ldi.

Ko'pchilik aytishi mumkin eyay bilan uje shunaqa holatdamiz deb. Ammo bizda no AI/LLM policy. Shu sabab development timeni ham raqobatdosh qilishimiz kerak. Bular juda juda context dependent mavzualr ammo o'zimga ham qiziq anchalik development timeni improve qila olamiz va buning uchun skilldan tashqari yana nimalar kerak. Masalan ekotizim qanday bo'lishi kerak etc...