Fix typo

Co-authored-by: Rémy Rakic <remy.rakic+github@gmail.com>

Author: Kobzol

content/rust-compiler-performance-survey-2025-results/index.md

@@ -164,7 +164,7 @@ More than 35% users said that they consider the IDE and Cargo [blocking one anot
 
 Around 20% of participants responded that clean builds are a significant blocker for them. In order to improve their performance, you can try a recently introduced experimental Cargo and compiler option called [`hint-mostly-unused`][hint-mostly-unused], which can in certain situations help improve the performance of clean builds, particularly if your dependencies contain a lot of code that might not actually be used by your crate(s).
 
-One area where clean builds might happen often is Continuous Integration (CI). 1495 respondents said that they use CI to build Rust code, and around 25% of them consider its performance to be a big blocker for them. However, almost 36% of respondents who consider CI build performace to be a big issue said that they do not use any caching in CI, which we found surprising. One explanation might be that the generated artifacts (the `target` directory) is too large for effective caching, and runs into usage limits of CI providers, which is something that we saw mentioned repeatedly in the open answers section. We have recently introduced an experimental Cargo and compiler option called [`-Zembed-metadata`][cargo-no-embed-metadata] that is designed to reduce the size of the `target` directories, and work is also underway to regularly [garbage collect][cargo-garbage-collect] them. This might help with the disk space usage issue somewhat in the future.
+One area where clean builds might happen often is Continuous Integration (CI). 1495 respondents said that they use CI to build Rust code, and around 25% of them consider its performance to be a big blocker for them. However, almost 36% of respondents who consider CI build performance to be a big issue said that they do not use any caching in CI, which we found surprising. One explanation might be that the generated artifacts (the `target` directory) is too large for effective caching, and runs into usage limits of CI providers, which is something that we saw mentioned repeatedly in the open answers section. We have recently introduced an experimental Cargo and compiler option called [`-Zembed-metadata`][cargo-no-embed-metadata] that is designed to reduce the size of the `target` directories, and work is also underway to regularly [garbage collect][cargo-garbage-collect] them. This might help with the disk space usage issue somewhat in the future.
 
 One additional way to significantly reduce disk usage is to reduce the amount of generated debug information, which brings us to the next section.