ParticleSystem will only update ParticleComponent when they exist, which happens rarely, just on collisions, etc. The rest of the time it's polling to find entities with ParticleComponent.
Isn't this polling inefficient?
No, it's not efficient, but there's no reason to do it that way and no (good) ECS implementation will poll for components.
When a component/entity is created, add the component/entity to the systems's list of active objects if the object meets the appropriate requirements (some systems require a combination of components, sometimes called a "component signature" by hip youthful people). Then the system consistently has an accurate list of all objects it needs to update and the information it needs to access them efficiently, no polling required.
This is true in an ECS architecture or other component architectures. Our engine is a very far cry from ECS and yet we do the same thing: components call something like game.SomeManager.addComponent(this) in their initialization function and game.SomeManager.removeComponent(this) in their shutdown function. Fancier ECS architectures automate that, but it's the same idea.
I would have assumed that libraries like EntityX are actually doing this under the hood, but I could be wrong. Every single off-the-shelf open source entity library I've ever seen on GitHub (EntityX included) is hot flaming garbage and I'd recommend that you run screaming in the opposite direction, anyway. If you think you need a complex library to manage your game objects, that's a sign that you're massively over-complicating the problem. And if you're using some crazy template meta-programming nonsense (like EntityX) you're potentially shooting yourself in the foot (that stuff will have trouble scaling past the smallest and simplest hobby games, especially if you at all value the time lost waiting for your game to compile).
