🚀 go-pugleaf

On 2020-11-05 15:26:23, heby wrote:
> On 05/11/2020 13:43, michal.lyszczek@bofc.pl wrote:
> > Dodatkowo, zmierzyłeś
> > że problem z wydajnością jest spowodowany przez select/poll?
> 
> Apliakcja wykonuje miliony ::read( *foo, 4 );. Ogólnie wykonuje bardzo dużo
> małych read na namedpipe, bezustannie komunikujac się z inną apliakcją (inny
> proces). Przypuszczam że każdy ::read to switch kontekstu do kernela, albo
> przynajmniej jakieś cieżkie operacje na granicy kernel/user space.

I to jest twój główny problem. Wołanie ciągle read(2) z tak małym
parametrem count rozwala ci całkowicie wydajność. Jak sam piszesz,
każdy read(2) to przejście do kernela, a to jest bardzo droga operacja,
zwłaszcza jak robisz "miliony" tego.

Moja propozycja rozwiązania jak wcześniej. Niech 1 wątek czyta ciągle
w pętli deskryptor, z dużym rozmiarem (jak 10kB), jak będzie mniej
danych niż 10kB to read(2) wyjdzie i zwróci liczbę odczytanych bajtów.
Te dane wrzucaj na kolejkę synchronizowaną i niech sobie reszta wątków
czyta to nawet i po 1 bajcie. Wołanie funkcji jest kilka rzędów wielkości
szybsze niż wołanie syscalla.

-- 
.-----------------.-------------------.---------------------.------------------.
| Michal Lyszczek | Embedded C, Linux |   Company Address   |  .-. open source |
| +48 727 564 419 | Software Engineer | Leszczynskiego 4/29 |  oo|  supporter  |
| https://bofc.pl `----.--------------: 50-078 Wroclaw, Pol | /`'\      &      |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP:  813 349 58 78 |(\_;/) programer  |
`----------------------^--------------^---------------------^------------------'