| 1 | | I have to say, this was a nightmare to track down. I thought atoms.radii would be slow because of atom typing, but that only takes ~3 seconds. I had a dickens of a time finding where the rest of the time was going. Turns out it's about 30 seconds between when the atom typing finishes and it returns to the caller(!). Ah, something funky with destructors them. None of the obvious std::set or std::map culprits did a thing when I changed them to static so they wouldn't get destroyed. After being flummoxed for awhile, I resorted to sending an ABRT signal to the process during that 30 seconds so I could get a stack trace. That revealed that it was the destruction of the temporary rings that the typing computes, in particular the destruction-notification overhead. After a few false starts, I managed to revamp the code so that these temporary rings don't engage the destruction-notification machinery. |
| | 1 | I have to say, this was a nightmare to track down. I thought atoms.radii would be slow because of atom typing, but that only takes ~3 seconds. I had a dickens of a time finding where the rest of the time was going. Turns out it's about 30 seconds between when the atom typing finishes and it returns to the caller(!). Ah, something funky with destructors then. None of the obvious std::set or std::map culprits did a thing when I changed them to static so they wouldn't get destroyed. After being flummoxed for awhile, I resorted to sending an ABRT signal to the process during that 30 seconds so I could get a stack trace. That revealed that it was the destruction of the temporary rings that the typing computes, in particular the destruction-notification overhead. After a few false starts, I managed to revamp the code so that these temporary rings don't engage the destruction-notification machinery. |
![[ChimeraX Issue Tracking System]](/trac/ChimeraX/chrome/site/ChimeraX-icon.svg){kind=icon}
