Do replicated/parameterized etc volumes improve runtime performance?

If I want to place many copies of a volume into a parent, I can either create a single G4PVPlacement for each copy in a loop (calculating all of the coordinates manually) or, if the volumes and coordinates fit certain criteria, I can use the various approaches described in the “Repeated Volumes” section of the user guide (PVReplica, PVDivision, ReplicatedSlices, etc.)

My question is, are these classes provided solely as a convenience to the developer, or should there be a runtime performance (compared to using many G4PVPlacements)? E.g., obviously there will be less memory use due to fewer physical volume objects instantiated. For my case where the parameterization would save maybe 100 volumes at most, this seems irrelevant. Is there any improvement in tracking performance, or a more substantive memory saving?

For context, I ask because I am trying to model a nearly symmetric arrangement of boolean volumes. To use repeated volumes, I would need to make some approximations in the design to be fully symmetric and to avoid use of booleans. If there is no significant performance improvement then there is no strong reason to do so.

The performance increase is primarily in memory footprint. When the geometry is closed and voxelized, the resulting voxelization should be the same whether regardless of the structure.

For your case of a “nearly symmetric” but not quite symmetric layout (a situation we have in my experiment’s geometry as well), you may find that G4PVParameterised with G4VPVParameterisation is useful. The latter (where you write a concrete subclass) returns the position, orientiation, etc. for your object based on the copy number as input.

The constituent volumes don’t have to be contiguous or anything; you specify a mother volume in which they should all be placed, and they can be put anywhere (even a random 3D distribution!). If you’re having to compute coordinates anyway for your placements in a loop, you can do that in the G4VPVParameterisation subclass.