Bug 41283

GemStone/S 64 Bit

3.7.1, 3.7, 3.6.8, 3.6.7, 3.6.6, 3.6.5, 3.6.4, 3.6.3, 3.6.2, 3.6.1, 3.6, 3.5.8, 3.5.7, 3.5.6, 3.5.5, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5, 3.4.5, 3.4.4, 3.4.3, 3.4.2, 3.4.1, 3.4, 3.3.9, 3.3.8, 3.3.7, 3.3.6, 3.3.5, 3.3.4, 3.3.3, 3.3.1, 3.3, 3.2.16, 3.2.15, 3.2.14, 3.2.13, 3.2.12, 3.2.11, 3.2.10, 3.2.9, 3.2.8.1, 3.2.8, 3.2.7, 3.2.x, 3.2, 3.1.0.6, 3.1.0.5, 3.1.x, 3.0.1, 3.0, 2.4.8, 2.4.7, 2.4.6, 2.4.5.1, 2.4.5, 2.4.4.8, 2.4.4.7, 2.4.4.x, 2.4.x, 2.4, 2.3.x, 2.2.6.5, 2.2.5.4, 2.2.x

All platforms

ProfMonitor over user action code can be biased

When the ProfMonitor sample timer fires while user action C code is executing, the sample is not actually taken until control returns back to smalltalk. This is usually when the user action code finishes and control has returned back to the calling smalltalk method.  But if the user action code makes a smalltalk callback, the sample will be taken in that smalltalk method. In both cases this can result in a sampling bias toward these methods, leading to higher than expected tally counts and percentages for these methods.

Workaround

Versions 3.3 and later allow real-time profiling as an alternative to elapsed time.  Include #real in the array passed to the ProfMonitor method with the options keyword.


                

Last updated: 10/25/23