Re: tweaking MemSet() performance
От | Bruce Momjian |
---|---|
Тема | Re: tweaking MemSet() performance |
Дата | |
Msg-id | 200209012341.g81NfCp01026@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: tweaking MemSet() performance (Andrew Sullivan <andrew@libertyrms.info>) |
Список | pgsql-hackers |
OK, seems we have wildly different values for MemSet for different machines. I am going to up the MEMSET_LOOP_LIMIT value to 1024 because it seems to be the best value on most machines. We can revisit this in 7.4. I wonder if a configure test is going to be required for this evenutally. I think random page size needs the same handling. Maybe I should add to TODO: o compute optimal MEMSET_LOOP_LIMIT value via configure. Is there a significant benefit? Can someone run some query with MemSet vs. memset and see a timing difference? You can use the new GUC param log_duration I just committed. Remember, I added MemSet to eliminate the function call overhead, but at this point, we are now seeing that MemSet beats memset() for ordinary memory setting, and function call overhead isn't even an issue with the larger buffer sizes. --------------------------------------------------------------------------- Andrew Sullivan wrote: > On Thu, Aug 29, 2002 at 11:07:03PM -0400, Bruce Momjian wrote: > > > > Would you please retest this. I have attached my email showing a > > simpler test that is less error-prone. > > Ok, here you go. Same machine as before, 2-way UltraSPARC-II @400 > MHz, 2.5 G, gcc 2.95.3, Solaris 7. This gcc compiles 32 bit apps. > > MemSet(): > > *64 > > real 0m1.298s > user 0m1.290s > sys 0m0.010s > *128 > > real 0m2.251s > user 0m2.250s > sys 0m0.000s > *256 > > real 0m3.734s > user 0m3.720s > sys 0m0.010s > *512 > > real 0m7.041s > user 0m7.010s > sys 0m0.020s > *1024 > > real 0m13.353s > user 0m13.350s > sys 0m0.000s > *2048 > > real 0m26.178s > user 0m26.040s > sys 0m0.000s > *4096 > > real 0m51.838s > user 0m51.670s > sys 0m0.010s > > and memset() > > *64 > > real 0m1.469s > user 0m1.460s > sys 0m0.000s > *128 > > real 0m1.813s > user 0m1.810s > sys 0m0.000s > *256 > > real 0m2.747s > user 0m2.730s > sys 0m0.010s > *512 > > real 0m12.478s > user 0m12.370s > sys 0m0.010s > *1024 > > real 0m26.128s > user 0m26.010s > sys 0m0.000s > *2048 > > real 0m57.663s > user 0m57.320s > sys 0m0.010s > *4096 > > real 1m53.772s > user 1m53.290s > sys 0m0.000s > > A > > -- > ---- > Andrew Sullivan 204-4141 Yonge Street > Liberty RMS Toronto, Ontario Canada > <andrew@libertyrms.info> M2P 2A8 > +1 416 646 3304 x110 > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления:
Следующее
От: "Giuseppe R. Papavero"Дата:
Сообщение: Possible ODBC Driver Bug (via VC++/MFC CRecordset)