On Saturday, August 19, 2017 at 11:17:57 PM UTC+2, fir wrote:
> gdy wydajnosc jest istotna to nawet zwykle wskazniki nie sa wskazane imo
>
> (kiedys mierzylem ile wolniejszy jest kod gdy dzialasz na tablicy
> bedacej wynikiem malloka w stosunku do w pewlni statycznej - i na
> malloku bylo auwazalnie 10-20% wolniej
Kiedyś chyba też widziałem różnice, ale to był bardzo dawno temu. Teraz
chyba tak się nie dzieje na nowych kompilatorach, na nowym sprzęcie i
na nowych bibliotekach/systemach?


> no ale niewazne moze to byla specyficzne sytuacje, podaje jako
> anegdote, ostatnio az tak bardzo nie przejmuje sie wydajnoscią
A ja jakoś ciągle mam z wydajnością problem. Wciąż szukam
szybszych: komputerów, implementacji, algorytmów, opcji kompilatora...
Może za trudne zadania liczę. Np. teraz się martwię, czy nie powinienem
zamienić drzew czerwono czarnych, na b-drzewa. Może wyszukiwanie w
b-drzewach byłoby na tyle szybkie, że nie trzeba robić sztuczki z
sortowaniem? Czasami będę miał rozkład prawie równomierny i
po posortowaniu będę mógł zastosować wyszukiwanie interpolacyjne.
Liczy się przyspieszenie o każde 10%.



> - nawet moge
> powiedziec, kiedys stawialem chyba gdzies tu pytanie jak ktos
> zrobilby trzymanie zawartosci edytora tekstowego w programie w c i
> kombinowalem wtedy cos w kierunku trzymania listy litych kawalkow
> ramu po powiedzmy okolo 500 kb kazdy - dzis
> raczej chyba zrobilbym przynajmniej na poczatek do testu tak ze
> kazda linijka w edytrze po prostu bylaby na odzielnym malloku
> (realokowany w miare
> edycji itd)
Czasami każdy edytor potrafi się zaciąć, gdy niechcący klikniemy na
pliku tekstowym o rozmiarze setek megabajtów lub o długich wierszach.
Musisz odpowiedzieć sobie na pytanie, do czego taki edytor ma
być używany. Nie ma jednego najlepszego rozwiązania do wszystkich
danych, ale jest jedno najlepsze rozwiązanie do rozkładu prawdopodobieństwa
tychże danych.

Pozdrawiam