Re: One process per session lack of sharing
От | Andres Freund |
---|---|
Тема | Re: One process per session lack of sharing |
Дата | |
Msg-id | 20160719181951.zzb4jsy2gurehpqb@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: One process per session lack of sharing (AMatveev@bitec.ru) |
Список | pgsql-hackers |
On 2016-07-19 14:18:22 +0300, AMatveev@bitec.ru wrote: > Hi > > > > Using TLS will slow down things noticeably though. So if we were to go > > there, we'd have to make up for some constant slowdown. > I can not understand why? > > I've read > https://msdn.microsoft.com/en-us/library/windows/desktop/ms686749(v=vs.85).aspx > and > http://david-grs.github.io/tls_performance_overhead_cost_linux/ > """ > The results are quite straightforward: no overhead at all. > """ > > 0x0000000000404f40 <+0>: inc DWORD PTR [rip+0x202382] > vs > 0x0000000000404f50 <+0>: inc DWORD PTR fs:0xfffffffffffffffc Not really true IIRC. For one segment offset stuff is encoded more widely, and for another, it'll generate more uops in many microarchitectures. Also, we actually *do* qualify for the exception in the blog you linked above: We have a fair amount of dynamically linked code.
В списке pgsql-hackers по дате отправления: