radiation_map_setup Performance with Bunch Tracking

[electronsandstuff]

Hey folks, I am debugging a performance problem related to bunch tracking with radiation fluctuations turned on and thought I would open a github issue related to this.

I have made a minimal working example of tracking a bunch with CSR and radiation fluctuations which is on the CLASSE file system at the path /nfs/acc/temp/electronsandstuff/csr-radiation-profiling. In order to profile the code, I was able to compile bmad + tao with debugging symbols enabled and can then run it with the OSX "Instruments" tool due to grpof not being available on that OS.

The results are below.

One of the most expensive parts of the calculation is the subroutine radiation_map_setup which takes up about 20% of the programs running time. It seems to be called for every particle in the bunch and at first I thought it was the calculation of the map itself that was causing performance problems. However, looking into the code it seems like there is some caching already there (ie the ele%rad_map%stale check).

Instead, it seems like all of the time is getting spent in memory operations related to the two ele_struct objects which are performed regardless of whether it computes the radiation map or not. If there was a way to avoid doing these memory operations for every particle, the tracking could probably be sped up quite a bit. Maybe the stale check could be done in track1_radiation instead before the setup code is called?

[DavidSagan]

A quick running of the revised code shows a time improvement of around 12%. I will investigate further...

[DavidSagan]

Fixed based upon PR #532 implemented.

[electronsandstuff]

Thanks! Looks like things scale with the number of particles. Got a pretty solid speedup with the new code for my application.