# Performance Issues with Gramps

**URL:** <https://gramps.discourse.group/t/performance-issues-with-gramps/5350>\
**Category:** Development\
**Tags:** hacks, performance\
**Created:** [April 28, 2024, 8:24pm UTC](https://gramps.discourse.group/t/performance-issues-with-gramps/5350 "2024-04-28T20:24:50Z")\
**Posts on this page:** 1\
**Showing post:** 36

<div class="post-metadata">

**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\
**Post date:** [April 29, 2024, 6:27pm UTC](https://gramps.discourse.group/t/performance-issues-with-gramps/5350/36 "2024-04-29T18:27:33Z")

</div>

> [@Nick-Hall](#):
>
> My prototype provided a quick solution that could use our existing database. So why wasn’t it implemented? There actually wasn’t much interest. Most of our users have trees with under 20,000 people and don’t suffer from performance issues. I also fall into this category, but I sympathise with users who have larger trees.

How about swapping in @kku’s Filter+ gramplet variation for 5.3 and inviting people to do some testing with a few sample Trees? The project could gather some statistics from a wide variety of hardware configurations.

Also perhaps you could add a Cache scaling preference?  
So users could dynamically have Gramps incrementally scale when record count exceeds a certain base number?

We have a LOT of filter rule requests in MantisBT [listed in another thread.](https://gramps.discourse.group/t/addon-filter-rule-requests/4148). They could be a good project for the community to work on as experiments for boosting Query performance.

---

_[View the full topic](https://gramps.discourse.group/t/performance-issues-with-gramps/5350)._
