3 ms·

> Disclaimer: This website is maintained by SourceHut. Note that I'm not insinuating that the data is incorrect ... sometimes comparisons like this omit unflat

• ddevault 7y ago
  I tried to avoid this, for example deliberately including blame - which sr.ht does not support - and a few hard pages that we slip out of the 90-100 range for. I am definitely interested in expanding the test suite with harder stuff. I want to use this to set goals for performance improvements and feature development - not just to show off how fast sr.ht is. I also want to get those accessibility numbers up - right now, Bitbucket has consistently impressive scores across the board on that metric.
  • smoyer 7y ago
    I'm not really enough of an expert to know what operations were missing and/or what might have really different implementations on the different systems. It "seemed" pretty consistent to me ... and leaving the yellow-orange values in the SH column was a good sign too. I have extensive experience with both Github and Gitlab and I can say that, in general, the performance on the operations match my experience. I don't want to say that's a fair comparison either as we self-host Gitlab and the performance (or lack thereof) could be our own fault. In any case, thanks for putting this together and kudoes to allowing the community to help add, adjust and comment on the metrics you've chosen.