Hi,
I've been looking for optimisation opportunities, and have discovered that ::seconds() (src/misc/time.cc) is taking up quite a lot (around a fifth) of CPU time.
As a quick test, I inserted the line "return 0.0;" at the top of this function. The time savings were substantial, and it didn't cause any immediately obvious problems.
I am not sure why seconds() is being called so frequently. It seems a little pointless, though, to call the underlying system call (gettimeofday() on my computer) more than once a second. My suggestion would therefore be to hook into SIGALRM and update a volatile variable once a second in the signal handler, then simply read the value of this variable in seconds(). This would make calling ::seconds() almost free in terms of CPU time.
One complication is that Wrspice already hooks into SIGALRM (wrspice/bin/wrspice.cc, line 1357 onwards), but comments in the code indicate that this is used for security tests, and is therefore presumably obsolete.
Hi,
I've been looking for optimisation opportunities, and have discovered that ::seconds() (src/misc/time.cc) is taking up quite a lot (around a fifth) of CPU time.
As a quick test, I inserted the line "return 0.0;" at the top of this function. The time savings were substantial, and it didn't cause any immediately obvious problems.
I am not sure why seconds() is being called so frequently. It seems a little pointless, though, to call the underlying system call (gettimeofday() on my computer) more than once a second. My suggestion would therefore be to hook into SIGALRM and update a volatile variable once a second in the signal handler, then simply read the value of this variable in seconds(). This would make calling ::seconds() almost free in terms of CPU time.
One complication is that Wrspice already hooks into SIGALRM (wrspice/bin/wrspice.cc, line 1357 onwards), but comments in the code indicate that this is used for security tests, and is therefore presumably obsolete.