# Performance loss with PGraphics and SVG

**URL:** https://discourse.processing.org/t/performance-loss-with-pgraphics-and-svg/12897
**Category:** Coding Questions
**Created:** [July 22, 2019, 8:25pm UTC](https://discourse.processing.org/t/performance-loss-with-pgraphics-and-svg/12897 "2019-07-22T20:25:13Z")
**Posts on this page:** 1
**Showing post:** 14

<div class="post-metadata">

### Author: ![hamoid](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/hamoid/32/58_2.png) [@hamoid](https://discourse.processing.org/u/hamoid)
#### Post date: [September 13, 2019, 9:03am UTC](https://discourse.processing.org/t/performance-loss-with-pgraphics-and-svg/12897/14 "2019-09-13T09:03:42Z")

</div>

I would use visualvm to find the bottleneck. Otherwise you can do random attempts at optimizing, but you may or may not find the bottleneck.

Random ideas:

- Check how many vertices each brick has. Maybe they are too detailed.
- Does the computer have good CPU and GPU?
- Do you need `stroke()` in the bricks? That involves more work than just `fill()`
- Calling `color()` each time is not necessary if the color doesn’t change (for instance you could store `color(255)` in a variable called white.
- I believe calling `.setStroke()` and `.setFill()` iterates over each vertex and changes its properties. Using a shader to affect rendering might be faster (if the bottleneck is CPU bound).

---

_[View the full topic](https://discourse.processing.org/t/performance-loss-with-pgraphics-and-svg/12897)._