Ta tiden og rapportér hvor lang tid ExtensionModule.execute() tar

RosenborgSupporterSoftware / RUSK

RBKweb Ultimate Survival Kit

MIT License

1 stars 2 forks source link

Ta tiden og rapportér hvor lang tid ExtensionModule.execute() tar #56

Closed havremunken closed 5 years ago

havremunken commented 5 years ago

Mine moduler så langt har vært skrevet helt uten noe forsøk på å måle eller optimalisere ytelse.

En funksjonalitet som måler hvor lang tid hver execute tar og rapporterer dette, kanskje med varsel i log om det går over en terskel, hadde vært fint for å avdekke om vi på litt sikt skal se på litt optimalisering også.

larsjaas commented 5 years ago

Det hadde tatt deg kortere tid å implementere det enn å legge inn issuen ;)

havremunken commented 5 years ago

Enig, prøver bare å legge meg til en vane om å få tanker som faller inn i skallen inn her ASAP, så jeg slipper å falle ut av tankerekka/koderekka jeg er i. Ellers må man branche og committe og så begynne på en annen ting og det blir pes.

Also, ting jeg legger ut her får et ekstra par øyne på seg fra deg, mens hvis jeg bare bestemmer meg for noe etter innfallsmetoden er det på master før noen med gangsyn har vurdert om det er en god idé.... :P

larsjaas commented 5 years ago

Du kan jo bare legge en sånn innstikker-commit rett inn i branchen du holder på med, og flytte den fremst eller sist når branchen din begynner å bli "ferdig" vha "git rebase -i master" - den lar deg jo også endre rekkefølge og droppe commits, ikke bare squash, pick, og edit.

havremunken commented 5 years ago

Jeg prøvde den rebase -i master saken for å squashe noe, den svikta noe grustomt her. Vet ikke hvorfor, men den avbrøt hele greia og kom seg ikke av flekken så jeg måtte slette .git/rebase-merge/ manuelt for å ha en sjanse.

Moralen i historien er: Bli mer kjent med git.

Og lag flere lokale branches.

havremunken commented 5 years ago

Men bare for å sneie innom temaet, har laget en greie som måler dette hjemme i morges - målingen er selvfølgelig triviell. Så sender den en melding med modulen, URLen og antall millisekunder det tok (burde sikkert få med versjonen på et tidspunkt også). Vurderer om det kan lagres unna et sted (chrome eller localStorage eller noe) sånn at det går an å hente frem en "topp 10 verste"-liste i UI eller noe... Kanskje eksportere topp-statistikken som JSON, jeg vet ikke.

larsjaas commented 5 years ago

Jeg prøvde den rebase -i master saken for å squashe noe, den svikta noe grustomt her. Vet ikke hvorfor, men den avbrøt hele greia og kom seg ikke av flekken så jeg måtte slette .git/rebase-merge/ manuelt for å ha en sjanse.

Det er som regel git som har rett i slike situasjoner ;) Alltid kjekt å kunne strukturen under .git/ uansett, og så er jo git reflog og git reset --hard veldig kjekk når man trenger tidsmaskin for å spole tilbake til før man bega seg ut på en ambisiøs merge-ekskursjon...

havremunken commented 5 years ago

Jeg tviler ikke på at git hadde rett, men lurer på om den tryna fordi jeg har VS Code som editor, og den sa noe om "waiting for your editor process to return" eller noe, så returnerte vel kallet mot code umiddelbart selv om editoren var åpen, og så stod jeg der i shell uten å komme noen vei.

Jeg har ikke satt meg inn i reflog & co, men har skjønt at det er en verden av moro der. Also noen ganger så er det veldig fint å klone ned en ny kopi fra github og så bare få inn de filene man faktisk ønsker endret fra det havarerte directoriet, selv om det er feigt... ;)

havremunken commented 5 years ago

Dette issuet er ferdig, selv om det gjenstår å gjøre noe med dataene det genererer.