jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • JRuby
  • JRUBY-1681

Pathological slowdown in Array#insert

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Not A Bug
  • Affects Version/s: JRuby 1.1.1
  • Fix Version/s: None
  • Component/s: Performance
  • Labels:
    None
  • Environment:
    ruby 1.8.5 (2007-11-25 rev 4842) [i386-jruby1.1b1], OS X 10.4.11

Description

Like MRI, JRuby's Array#insert method becomes very slow with high numbers of iterations. Below is a snippet, which is also included as part of the bench_array.rb program in ruby_test:

require "benchmark"

MAX = 200000

Benchmark.bm(35) do |x|
   x.report("Array#insert"){
      array = [1,2,3,4]
      MAX.times{ array.insert(2, "a", "b") }
   }
end

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Marcin Mielzynski added a comment - 07/Dec/07 7:43 AM

Yeah, we need a bit different approach than MRI takes here, there's still room for improvement in Array (especially for this case). But remember, we don't have realloc in java.

Show
Marcin Mielzynski added a comment - 07/Dec/07 7:43 AM Yeah, we need a bit different approach than MRI takes here, there's still room for improvement in Array (especially for this case). But remember, we don't have realloc in java.
Hide
Permalink
Marcin Mielzynski added a comment - 09/May/08 2:00 PM

With -XX:+UseParallelGC jruby is 2x faster than 1.9 for 100000.times{ array.insert(2, "a", "b") }.

Show
Marcin Mielzynski added a comment - 09/May/08 2:00 PM With -XX:+UseParallelGC jruby is 2x faster than 1.9 for 100000.times{ array.insert(2, "a", "b") }.
Hide
Permalink
Charles Oliver Nutter added a comment - 04/Feb/09 4:56 AM

This is simply an artifact of how arrays are grown. We grow at roughly the same rate as MRI, which means we have to expand and copy every time the array needs to be larger. When this is done thousands of times, we generate a lot of garbage and have to do a lot of copying. Because we don't have realloc, the best we can do is hope that Java's GC and arraycopy will keep up. For the moment, it appears that they do; we're slightly faster than 1.8.

Show
Charles Oliver Nutter added a comment - 04/Feb/09 4:56 AM This is simply an artifact of how arrays are grown. We grow at roughly the same rate as MRI, which means we have to expand and copy every time the array needs to be larger. When this is done thousands of times, we generate a lot of garbage and have to do a lot of copying. Because we don't have realloc, the best we can do is hope that Java's GC and arraycopy will keep up. For the moment, it appears that they do; we're slightly faster than 1.8.

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Daniel Berger
Vote (0)
Watch (3)

Dates

  • Created:
    07/Dec/07 7:38 AM
    Updated:
    27/Oct/09 1:48 PM
    Resolved:
    04/Feb/09 4:56 AM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.