🚀 go-pugleaf

Dnia 2007-11-10, Piotr Wyderski napisał:
> Łukasz Krotowski wrote:
>> Mówiąc zupełnie szczerze, ostatnimi czasy wąskim gardłem są dla mnie
>> dyski i baza.
>
> Na interfejsach do baz się zupełnie nie znam, ale w przypadku dysków
> polecam tryb asynchroniczny oparty na completion ports oraz wyłączenie
> cache'owania plików.

O nie, nie przerobię obecnego rozwiązania na IOCP jeśli _naprawdę_ nie
będę musiał. Zbyt duża komplikacja, konieczność utrzymywania rozłącznych
mechanizmów dla Win32 i Linuksa itp. Nie opłaca się. ;)

>> Nie. Załóżmy, że masz jakiś kawałek programu który działa na pewnej,
        ^^^^^^^^^^^
>> znanej ilości pamięci (stałej, bądź jako funkcja wejścia). Wtedy możesz,
>> z nonszalanckim ,,a co mi tam'', wszystkie kontenery z tego kawałka
>> programu przestawić na alokator który tylko alokuje. A po zakończeniu,
>> jednym pool.release() zwolnić całą pamięć.
>
> No ale ja nie wiem, ile pamięci mi będzie potrzeba. Wiem tylko,
> ile dla typowych danych powinno wystarczyć. Jeśli będzie więcej,
> to całość dalej ma działać poprawnie.

Czyli Twoja sytuacja nie spełnia wymaganych założeń (podkreślone).
Pisałem o sytuacji gdy wiesz ile pamięci potrzeba. Np. wiesz, że
przetwarzasz jednorazowo jeden obraz. Każdy z obrazów ma ściśle
określone wymiary.

>>>> albo przeciągnę sobie życie local_pool przez więcej
>>>> niż jedno wywołanie funkcji to będę szybszy. (*)
>>>
>>> Nie nadążam. Masz darmowe budowanie rekordów aktywacji?
>>> Ech, kombinujecie, Panocku, jak koń pod górę.
>>
>> Ja też nie nadążam. Skąd Ci się tutaj wzięły rekordy aktywacji?
>
> No skoro zamierzasz przekazywać wskaźnik na local_pool
> między funkcjami, to musisz go uczynić ich parametrem, a co
> za tym idzie budować rekordy aktywacji go zawierające przy
> każdym wywołaniu.

Nie, wskaźnik (w rzeczywistości referencja) na local_pool jest ustawiona
raz, jako globalna zmienna w alokatorze. A alokator używany jest w wielu
funkcjach.

-- 
Łukasz Krotowski | lukasz.krotowski_AT_gmail.com