*argv, VALUE ary) { long pos; if (argc < 1) { rb_raise(rb_eArgError, ”wrong number of arguments”); } rb_ary_modify_check(ary); if (argc == 1) return ary; pos = NUM2LONG(argv[0]); if (pos == -1) { pos = RARRAY_LEN(ary); } if (pos < 0) { pos++; } rb_ary_splice(ary, pos, 0, rb_ary_new4(argc - 1, argv + 1)); return ary; } class Array def insert(idx, *items) Rubinius.check_frozen return self if items.length == 0 idx = Rubinius::Type.coerce_to idx, Fixnum, :to_int idx += (@total + 1) if idx < 0 if idx < 0 raise IndexError, ”#{idx} out of bounds” end self[idx, 0] = items self end end (przeredegowano i usunięto to i owo w celu poprawy czytelności)
prostej aplikacji Rails 3.2 ▶ sinatra — 10 000 zapytań do jeszcze prostszej aplikacji w Sinatrze Nieżyciowe ▶ macierze — mnożenie macierzy (źródło: The Computer Language Benchmarks Game) ▶ wątki — to samo co kilka slajdów temu
przedstawionej na spotkaniu Warsaw Ruby Users Group w dniu 15.01.2013. W przeprowadzonym przeze mnie eksperymencie, w którym MRI zużywał na odśmiecanie pamięci 20% czasu procesora, w wypadku Rubinius czas spędzony w GC stanowił 5% łącznego czasu wykonania. Przed każdym spośród wykonanych testów dokonano uruchomienia, którego wyniki były odrzucane, aby pozwolić systemowi operacyjnemu na umieszczenie niezbędnych plików w pamięci podręcznej. Testy Ruby on Rails i Sinatra były prowadzone przy pomocy serwera in 1.5.0. Ze względu na fakt, że in korzysta z rozszerzeń napisanych w C, warto dokonać powtórnych testów na innych serwerach, np. (sic!) WEBrick. Czas odpowiedzi na zapytania HTTP mierzono przy pomocy ApacheBench 2.3. W wypadku obu maszyn wirtualnych testy poprzedzone były zadaniem tysiąca niemierzonych zapytań HTTP. Miało to na celu umożliwienie Rubinius rozpoczęcia kompilacji JIT przed właściwymi testami. Kod testów można uzyskać pod adresem https://bitbucket.org/jstepien/wrug-2013-01-15