|
| 1 | +# CSS Selector Performance Tests |
| 2 | + |
| 3 | +This directory contains performance tests for the WordPress HTML API CSS selector parsing functionality. |
| 4 | + |
| 5 | +## Test Files |
| 6 | + |
| 7 | +### wpCssSelectorPerformance.php |
| 8 | +Comprehensive performance tests that measure execution time for various CSS selector parsing scenarios: |
| 9 | + |
| 10 | +- **Type selectors**: `div`, `span`, `article`, etc. |
| 11 | +- **Class selectors**: `.class`, `.my-class`, etc. |
| 12 | +- **ID selectors**: `#id`, `#my-id`, etc. |
| 13 | +- **Attribute selectors**: `[attr]`, `[attr="value"]`, etc. |
| 14 | +- **Compound selectors**: `div.class#id[attr]` |
| 15 | +- **Complex selectors**: `div > p`, `nav ul li` |
| 16 | +- **Selector lists**: `div, p, span` |
| 17 | +- **Unicode selectors**: `.café`, `#résumé`, etc. |
| 18 | +- **Escaped selectors**: `.\\31 23`, `#\\2e test` |
| 19 | +- **Large selectors**: Complex selectors with many parts |
| 20 | +- **Malformed selectors**: Error handling performance |
| 21 | + |
| 22 | +### wpCssSelectorBenchmark.php |
| 23 | +Focused benchmark tests that measure throughput (operations per second) and memory usage: |
| 24 | + |
| 25 | +- **Throughput tests**: How many selectors can be parsed per second |
| 26 | +- **Memory scaling**: How memory usage scales with selector complexity |
| 27 | +- **Error handling**: Performance of parsing invalid selectors |
| 28 | +- **Real-world scenarios**: Performance with typical framework/theme selectors |
| 29 | + |
| 30 | +## Running Performance Tests |
| 31 | + |
| 32 | +### Run All Performance Tests |
| 33 | +```bash |
| 34 | +vendor/bin/phpunit tests/phpunit/tests/html-api/wpCssSelectorPerformance.php |
| 35 | +vendor/bin/phpunit tests/phpunit/tests/html-api/wpCssSelectorBenchmark.php |
| 36 | +``` |
| 37 | + |
| 38 | +### Run Specific Test Groups |
| 39 | +```bash |
| 40 | +# Run only performance tests |
| 41 | +vendor/bin/phpunit --group performance |
| 42 | + |
| 43 | +# Run only benchmark tests |
| 44 | +vendor/bin/phpunit --group benchmark |
| 45 | + |
| 46 | +# Run both performance and benchmark tests |
| 47 | +vendor/bin/phpunit --group performance,benchmark |
| 48 | +``` |
| 49 | + |
| 50 | +### Run Individual Tests |
| 51 | +```bash |
| 52 | +# Run a specific performance test |
| 53 | +vendor/bin/phpunit --filter test_compound_selector_parsing_performance tests/phpunit/tests/html-api/wpCssSelectorPerformance.php |
| 54 | + |
| 55 | +# Run a specific benchmark test |
| 56 | +vendor/bin/phpunit --filter test_simple_selector_parsing_throughput tests/phpunit/tests/html-api/wpCssSelectorBenchmark.php |
| 57 | +``` |
| 58 | + |
| 59 | +## Understanding Results |
| 60 | + |
| 61 | +### Performance Test Results |
| 62 | +Performance tests output timing information to error_log: |
| 63 | +``` |
| 64 | +Performance [Type Selector Parsing]: avg=0.05ms, min=0.03ms, max=0.12ms, iterations=1000 |
| 65 | +``` |
| 66 | + |
| 67 | +- **avg**: Average execution time in milliseconds |
| 68 | +- **min**: Fastest execution time |
| 69 | +- **max**: Slowest execution time |
| 70 | +- **iterations**: Number of test iterations |
| 71 | + |
| 72 | +### Benchmark Test Results |
| 73 | +Benchmark tests output throughput and memory information: |
| 74 | +``` |
| 75 | +[BENCHMARK] Simple Selector Parsing: 67543.21 ops/sec, 0.0148ms avg, 0.00KB memory, 0.00KB peak |
| 76 | +``` |
| 77 | + |
| 78 | +- **ops/sec**: Operations (parsings) per second |
| 79 | +- **avg**: Average time per operation in milliseconds |
| 80 | +- **memory**: Memory used during test in KB |
| 81 | +- **peak**: Peak memory usage in KB |
| 82 | + |
| 83 | +## Performance Expectations |
| 84 | + |
| 85 | +### Current Performance Thresholds |
| 86 | +- **Simple selectors**: > 50,000 ops/sec |
| 87 | +- **Compound selectors**: > 10,000 ops/sec |
| 88 | +- **Complex selectors**: > 5,000 ops/sec |
| 89 | +- **Selector lists**: > 3,000 ops/sec |
| 90 | +- **Attribute selectors**: > 8,000 ops/sec |
| 91 | +- **Unicode selectors**: > 15,000 ops/sec |
| 92 | +- **Error handling**: > 20,000 ops/sec |
| 93 | + |
| 94 | +### Memory Usage |
| 95 | +- Memory usage should scale roughly linearly with selector complexity |
| 96 | +- Error handling should not consume excessive memory |
| 97 | +- Memory leaks should be avoided during repeated parsing |
| 98 | + |
| 99 | +## Monitoring Performance |
| 100 | + |
| 101 | +### In CI/CD |
| 102 | +These tests can be integrated into CI/CD pipelines to: |
| 103 | +- Monitor performance regressions |
| 104 | +- Ensure performance standards are maintained |
| 105 | +- Compare performance across different PHP versions |
| 106 | + |
| 107 | +### Local Development |
| 108 | +Use these tests to: |
| 109 | +- Measure performance impact of code changes |
| 110 | +- Identify performance bottlenecks |
| 111 | +- Optimize parsing algorithms |
| 112 | + |
| 113 | +## Troubleshooting |
| 114 | + |
| 115 | +### Tests Failing Due to Performance |
| 116 | +If performance tests fail consistently: |
| 117 | + |
| 118 | +1. **Check system load**: High CPU usage can affect timing |
| 119 | +2. **Run multiple times**: Single runs may have variance |
| 120 | +3. **Update thresholds**: Hardware differences may require adjustment |
| 121 | +4. **Profile specific cases**: Use tools like Xdebug to identify bottlenecks |
| 122 | + |
| 123 | +### Adjusting Performance Thresholds |
| 124 | +Thresholds can be adjusted in the test files: |
| 125 | +- `wpCssSelectorPerformance.php`: Modify `PERFORMANCE_THRESHOLD_MS` constant |
| 126 | +- `wpCssSelectorBenchmark.php`: Modify assertion values in individual tests |
| 127 | + |
| 128 | +### Adding New Performance Tests |
| 129 | +When adding new selector functionality: |
| 130 | +1. Add parsing performance tests to `wpCssSelectorPerformance.php` |
| 131 | +2. Add throughput benchmarks to `wpCssSelectorBenchmark.php` |
| 132 | +3. Update this documentation with new performance expectations |
| 133 | + |
| 134 | +## Best Practices |
| 135 | + |
| 136 | +### Writing Performance Tests |
| 137 | +- Use realistic test data that represents actual usage |
| 138 | +- Include both positive and negative test cases |
| 139 | +- Test edge cases and error conditions |
| 140 | +- Consider memory usage alongside execution time |
| 141 | + |
| 142 | +### Interpreting Results |
| 143 | +- Look for trends over time, not just individual runs |
| 144 | +- Compare relative performance between different selector types |
| 145 | +- Consider the context of how selectors are used in real applications |
| 146 | +- Monitor both average and peak performance metrics |
| 147 | + |
| 148 | +### Optimization Guidelines |
| 149 | +Based on test results, focus optimization efforts on: |
| 150 | +- Most commonly used selector types |
| 151 | +- Cases with highest memory usage |
| 152 | +- Scenarios with slowest throughput |
| 153 | +- Error handling paths that are frequently exercised |
0 commit comments