Closed peabnuts123 closed 7 years ago
@peabnuts123 do you have a public repo where this is reproducible? I'd love to try some profiling, but would be great if I can see the same issues as you.
I don't sorry, as my codebase is a for a client at work. I'm sure you can locate a significantly sized Ember project somewhere on GitHub. Conversely, I cab also test it on a project that is significantly smaller than my current one and see if it is the size or another factor making it slow.
@peabnuts123 I just pushed 0.6 to the marketplace -- with any luck this will help with the perf issues. Please let me know, thanks!
Wicked! I will check it out 😃
Yes! It does appear to be performing perfectly now. I did also face / resolve some system performance issues around the search service since I made this issue which I'm sure had an impact too. Great job. I am definitely going to be adopting this now, would love to see something like #3 happen 😁
@peabnuts123 Excellent! re: #3 -- PR's are always greatly appreciated ;)
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
I'd like to use this wonderful customisable extension in favour of the framework-specific extension Ember Related Files. So I've written some rules for Ember which I am happy to share when I've finished them. However, i've found that in my project (of >2000 files) the pattern matching / locating can run a bit slowly. As pictured:
This is a bit of a pain. The Ember related files extension linked above does not have this delay, so I'm assuming there is some optimisation to be had.
For extra reference, here is my ruleset so far. It is also worth noting that I ONLY have this ruleset enabled, so it is only matching against these 5 rules: