You got it backwards. If I were to release a benchmark for Microdot, everyone would say that it is biased!

The article you are referring to is intended to benchmark microcontrollers running MicroPython. Nothing to do with Microdot.

I'm not really sure what conclusions you expect to reach if you had a Microdot benchmark that gives you a requests per second number. I would not stop using microcontrollers if the number was low, and I wouldn't start more projects if the number was high. I don't really care. It works for the intended purpose.

▲

Tepix 4 days ago | parent [-]

I think it would be valuable to decide if the performance is sufficient for a desired purpose. If the performance is insufficient you may need to switch to something written in a compiled language or to a faster platform. That's why the RPS is useful.

▲

miguelgrinberg 4 days ago | parent [-]

This is true for any kind of project, regardless of hardware or software stack. You always need to evaluate the performance for the specific use case you are targeting to make sure it falls in the expected range, and it is your job to do this evaluation as the project owner, because only you know the specifics of your project.

The point I was trying to make in my reply above was that an abstract RPS number, obtained measuring a general purpose web app on a general purpose microcontroller does not mean anything. What matters is your own performance evaluation.

	▲	simpaticoder 4 days ago \| parent [-]
		I think there is a fundamental misunderstanding caused by the OP's article. It mischaracterizes your blog post as a performance test of microdot, but as you say, it has nothing to do with it. Still, a baseline, best-case RPS number is a useful number to associate with microdot for various reasons; it cannot, of course, take the place of testing the real application, but what it can do is give implementers and upper-bound on IOPs to a device via HTTP/S. Take that as you will. Microdot is a very cool project, kudos for doing it and sharing it.