4 ms·

Without getting into the tests, I suspect he checked his code against the Symfony Routing component[0] instead of the entire framework stack. Symfony is build f

Without getting into the tests, I suspect he checked his code against the Symfony Routing component[0] instead of the entire framework stack. Symfony is build from stand-alone loosely decoupled components[1]. [0] https://packagist.org/packages/symfony/routing https://packagist.org/packages/symfony/routing [1] https://packagist.org/packages/symfony/ https://packagist.org/packages/symfony/

randomdrake 13y ago
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.
fooyc 13y ago
From the README, it also looks like that he didn't use the optimised (default) versions at all: "Pux tries not to consume computation time to build all routes dynamically (like Symfony/Routing). Instead, Pux compiles your routes to plain PHP array for caching, the compiled routes can be loaded from cache very fast."

randomdrake 13y ago

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.

fooyc 13y ago

From the README, it also looks like that he didn't use the optimised (default) versions at all: "Pux tries not to consume computation time to build all routes dynamically (like Symfony/Routing). Instead, Pux compiles your routes to plain PHP array for caching, the compiled routes can be loaded from cache very fast."