I gave him the benefit of the doubt and am assuming the same. Supposing it is the case, my previous concerns and questions still remain: 1) How was the compone

I gave him the benefit of the doubt and am assuming the same. Supposing it is the case, my previous concerns and questions still remain: 1) How was the component isolated and used for the test? 2) Do the features of the Symfony routing component match the features of Pux? This is exactly why I'm more upset at the presentation of the project and not the project itself. These questions wouldn't need to be answered if the README simply talked about what it did and how it performed. Instead, it positions itself as a competitor to a specific product and then tests against it. That would be fine, except the tests appear incomplete, very specific, and not a good comparison. In addition, it doesn't highlight the total throughput numbers or show off the maximum viable performance at all. It simply says it's better than something else. When you're selling something as being performant routing, that means you should be flaunting the maximum number of requests you were able to squeeze out of it. There isn't a single statement about how much you can really push through this until it fails. So, how is it interesting? When comparing performance, you have to know maximums. There are none here except for the amount of requests possible when requesting a single page at 10 concurrent users. The project stands alone as an interesting dive into attempting to speed up routing for specific use-cases. This sort of goes to the adage of product placement in that you shouldn't sell your product by simply talking about the competitor. Unless you execute it very, very well you stand to have your product lost in the noise.