- No właśnie tak napisałem: “Zależność występuje dla każdego indeksu > 0”.
- Przez “pierwszy” rozumiem 1, a nie 0.
Dla pierwszego znaku (indeks 0) wyniki benchmarku na mri 1.9.2:
0.000000 0.000000 0.000000 ( 0.001339)
0.000000 0.000000 0.000000 ( 0.000572)
Niemniej skok czasowy przy zmianie indeksu choćby o jeden jest odjechany.
Co ciekawsze, ten zwiększony czas wcale nie zależy od tego o którym indeksie mowa. Czas w drugiej pętli oscyluje wokół 2.9-3s.
Kod taki:
puts Benchmark.measure {
1000.times { k = s2[50000] }
}
jak i (żeby uniknąć zarzutów o cache)
puts Benchmark.measure {
1000.times { k = s2[rand(100_000)] }
}
Co trochę przeczy tezie o wyciąganiu O(n).
Moje podejrzenie jest takie, że przy każdym wywołaniu String#[] (prócz dla indeksu 0) skanowany jest cały ciąg (np. po to by sprawdzić czy zawiera poprawne znaki w stosunku do ustawionego kodowania) i dlatego czas rośnie wraz z ilością znaków + jest taki sam niezależnie od indeksu. Zgłosiłem już buga na redmine, myślę, że nie jest to zamierzone zachowanie.
Wygląda na to, że mogliby skorzystać z :
Link / id ticketa? 
Wow! To możemy sobie we trzech pogratulować 
Radarek - dzięki za założenie ticketa. Fajnie, że to od ręki poprawili.
Odpowiedz glownego zainteresowanego
[quote]Ryan: I’m not a fan of his solution, I much prefer to write the javascript in the rails action response
Ryan: A simple “data-update” works for some cases, but is not very flexible
Ryan: I often find the need to update more than one thing in an AJAX response
Ryan: if you find yourself using it often then that is called for a way to improve it, yes
right
Ryan: in the apps I’ve worked with I haven’t found that to be a source of duplication
usually my javascript response is at least a few lines long
doing multiple things[/quote]
[quote]Ryan: I’m not a fan of his solution, I much prefer to write the javascript in the rails action response
Ryan: A simple “data-update” works for some cases, but is not very flexible
Ryan: I often find the need to update more than one thing in an AJAX response
Ryan: if you find yourself using it often then that is called for a way to improve it, yes
right
Ryan: in the apps I’ve worked with I haven’t found that to be a source of duplication
usually my javascript response is at least a few lines long
doing multiple things[/quote]
Bullshit. Kod tak napisany zazwyczaj pełen duplikacji i ciężki w utrzymaniu. Ryan może mieć swoje zdanie, może mu to jakoś wychdzi dobrze, ale ile razy ja (zazwyczaj po obejrzeniu jakiegoś Railscasta) zaczynam używać tego w praktyce, wychodzi sieczka.
Może po prostu piszecie aplikacje o różnych potrzebach i sami w związku z tym macie różne potrzeby ? Ja na przykład nie widzę nic dziwnego z 100 zapytaniach per strona. Po prostu piszę backendowe aplikacje o tak skomplikowanych walidacjach i prawach dostępu, że tak musi być a przecież jakąś webową aplikację by to pewnie zabiło.
Nie widzę jakiegoś szczególnego problemu w napisaniu odpowiedzi zwracającej jsona z hashem gdzie klucz to byłby argument dla funkcji $ co ma zastać uaktualnione a wartością byłoby co ma tam wstawić. Wywołanie tej akcji byłoby oznaczone jednym data-atrybutem i po problemie. Wilk syty i owca cała zakładając, że chce się tylko podmienić parę miejsc na stronie. Ale jak już podmienić i podświetlić to wracamy do punktu wyjścia i odpowiedzi Rayana.
Korzystał ktoś z Apotomo?
[quote]Widgets for Rails
Forget about your cluttered RJS code. Throw away the messed up partial collection that gets out of control. Make your controllers slim, again. And dump your AJAX wire code and its countless routes!
Apotomo is a true MVC widget framework for Rails. Widgets are based on Cells and provide reuseable view components. Having bubbling events, they know when and how to update themselves via AJAX![/quote]
[quote=lewy313]Odpowiedz glownego zainteresowanego
[quote]Ryan: I’m not a fan of his solution, I much prefer to write the javascript in the rails action response
Ryan: A simple “data-update” works for some cases, but is not very flexible
Ryan: I often find the need to update more than one thing in an AJAX response
Ryan: if you find yourself using it often then that is called for a way to improve it, yes
right
Ryan: in the apps I’ve worked with I haven’t found that to be a source of duplication
usually my javascript response is at least a few lines long
doing multiple things[/quote]
[/quote]
Szukałem tej odpowiedzi na railscasts, ale nie znalazłem… Możesz podać źródło?
A co do meritum - zgadzam się, że każdy ma swoje zapatrywania dot. tego, jak łączyć aplikację pisaną w Rubim z kodem Javascriptowym. Osobiście wolę pisać w JS jak najmniej (w szczególności gdy JS jest przemieszane z Rubim). Co więcej - rozwiązanie, w którym w widoku mogę wprost podać to co ma być zaktualizowane, ma tę zaletę, że zwykle ten element jest definiowany w tym samym widoku, co pozwala łatwiej ogarnąć całość. Ponadto, takie rozwiązanie unika duplikacji trywialnego, powtarzalnego kodu. No i na koniec - ułatwi przesiadkę z Rails 2.x na Rails 3 z UJS.
Swoją drogą zaczynam dostrzegać negatywne efekty wydajnościowe UJS - jeśli na stronie jest jakieś 200 elementów, które mają przypisane różne akcje Javascriptowe, to przeglądarka (Firefox 3.6.8) muli tak, że nie jest w stanie np. pokazać ukrytego spinnera, w trakcie, kiedy realizowane jest żądanie AJAX. Nie miałem tego problemu, gdy korzystałem z “paskudnego” RJSa (a może to wina jQuery?)
Summa, summarum - wydaje mi się, że podejście oferowane np. przez ExtJS, gdzie od serwera oczekuje się jedynie danych w JSONie/HTMLu (bez JS), a logika “updateów/podświetleni/itp.” realizowana jest w całości przez bogate komponenty javascriptowe jest znacznie bardziej elegancka.
Też coraz bardziej skłaniam się w tą stronę - nigdy nie przemawiała do mnie idea generowania JS za pomocą helperów Ruby i później evalowania tego. Można myśleć o V w MVC jak o aplikacji działającej po stronie klienta i wtedy JS naturalnie staje się pełnoprawnym językiem programowania, a nie tylko manipulatorem HTMLa.
200 elementów to nie jest duża liczba dla nowych przeglądarek. Jeżeli te 200 elementów jest jakoś ze sobą powiązanych, tzn. jest to jakaś lista czy coś takiego, to spróbuj koniecznie użyć delegate, ustawisz wtedy jeden event dla wszystkich elementów, co znacząco potrafi poprawić wydajność.
Co do wydajności jeszcze - funkcje wrzucone w onclick są szybsze niż eventy. Pytanie tylko czy ma to aż tak duże znaczenie?
Wiesz że AgileZen wciąż dramatycznie muli w Firefoxie? 
[quote=drogus]200 elementów to nie jest duża liczba dla nowych przeglądarek. Jeżeli te 200 elementów jest jakoś ze sobą powiązanych, tzn. jest to jakaś lista czy coś takiego, to spróbuj koniecznie użyć delegate, ustawisz wtedy jeden event dla wszystkich elementów, co znacząco potrafi poprawić wydajność.
Co do wydajności jeszcze - funkcje wrzucone w onclick są szybsze niż eventy. Pytanie tylko czy ma to aż tak duże znaczenie?[/quote]
Różnica między onclick="" a Element.click() to nie tylko sama wydajność, a takie onsubmit to już wogóle. Cały Event Model w html to hax. Prototype a później jQuery wprowadziło nową jakość jeśli chodzi o Event Handling ale to też są nadal hacki. HTML5 już definiuje co to jest Event Handler a co to Event Listener, tylko teraz jak to będzie interpretowane przez vendorów.
Jeszcze w temacie HTML5. Testów oczywiście na HTML5 Event Model jeszcze nie ma, podobno mają być ale brakuje rąk do pracy (taką odpowiedź uzyskałem). Docelowo chcą mieć testy na wszystko w specyfikacji. Tutaj znajduje się całość tego co jest http://test.w3.org/html/tests/
Specyfikacje z testami to byłaby fajna rzecz