Bug #2264
Kernel#sleep thrashes the CPU on Windows
| Status: | Closed | Start date: | 10/25/2009 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | % Done: | 0% |
||
| Category: | core | |||
| Target version: | Ruby 1.8.7 | |||
| ruby -v: | ruby 1.8.7 (2009-06-12 patchlevel 174) [i386-mswin32_90] |
Description
The attached script demonstrates a problem with Kernel#sleep: calling it while other threads are running severely interferes on performance. (You don't see a diference if there are only idle threads, though.) These are the results on a P4 3.2GHz with Windows XP (SP 3):
before:
0.047000 0.000000 0.047000 ( 0.046875)
0.062000 0.000000 0.062000 ( 0.062500)
0.063000 0.000000 0.063000 ( 0.062500)
after:
9.359000 10.391000 19.750000 ( 20.109375)
9.438000 10.094000 19.532000 ( 19.859375)
9.890000 10.250000 20.140000 ( 20.468750)
I get similar results with ruby 1.8.7-p160, and it looks like the problem was introduced after Ruby 1.8.7-p72. Other branches are unaffected:
> ruby -v
ruby 1.8.6 (2009-08-04 patchlevel 383) [i386-mswin32_90]
> ruby test_sleep.rb
before:
0.062000 0.000000 0.062000 ( 0.062500)
0.063000 0.000000 0.063000 ( 0.062500)
0.078000 0.000000 0.078000 ( 0.078125)
after:
0.062000 0.000000 0.062000 ( 0.062500)
0.047000 0.000000 0.047000 ( 0.046875)
0.063000 0.000000 0.063000 ( 0.062500)
> ruby -v
ruby 1.8.7 (2008-08-11 patchlevel 72) [i386-mswin32]
> ruby test_sleep.rb
before:
0.047000 0.000000 0.047000 ( 0.047000)
0.062000 0.000000 0.062000 ( 0.062000)
0.047000 0.000000 0.047000 ( 0.047000)
after:
0.047000 0.000000 0.047000 ( 0.063000)
0.062000 0.000000 0.062000 ( 0.062000)
0.063000 0.000000 0.063000 ( 0.063000)
> ruby -v
ruby 1.9.1p0 (2009-01-30 revision 21907) [i386-mswin32]
> ruby test_sleep.rb
before:
0.031000 0.000000 0.031000 ( 0.031250)
0.031000 0.000000 0.031000 ( 0.031250)
0.031000 0.000000 0.031000 ( 0.031250)
after:
0.047000 0.000000 0.047000 ( 0.046875)
0.032000 0.000000 0.032000 ( 0.031250)
0.031000 0.000000 0.031000 ( 0.031250)
History
Updated by Yui NARUSE over 2 years ago
- Status changed from Open to Assigned
- Assignee set to Usaku NAKAMURA
Updated by Usaku NAKAMURA over 2 years ago
- Status changed from Assigned to Closed
Already fixed on ruby_1_8 branch, and shyouhei has stacked the patch on his backport list.