Humm.. thanks for this profiling! it is indeed called a lot of times, but I
don't know about the average time per call... and your
20ms optimization will it really do a diff ?
it's still 15% so I think it's good enough, but if we could make it go under
100ms, then I think we'll be able to see a
I do not see Alvaro's suggestion here, it's probably best.
Also, I think code readability is much more important than optimization.
This only does not hold in crucial parts of the code, like Youness said.
It is nice you found this difference though. I vote for Alvaro's
suggestion to add a boolean
Best way to make your point is having damn straight facts, here we go! JérômeCourriel: [EMAIL PROTECTED]MSN Messenger: [EMAIL PROTECTED]iChat & AIM: [EMAIL PROTECTED]Skype: germinator5000 Le 6 août 2006 à 20:28, Benjamin a écrit :I tried profiling abook.tcl with etprof.Procname : ::abook::setCon
I tried profiling abook.tcl with etprof.Procname : ::abook::setContactDataCallnumber : 2736 timesAverage time per call : 145 msProcname : ::abook::setContactDataFastCallnumber : 1693 timesAverage time per call : 125 ms
--- Benjamin[EMAIL PROTECTED]
--
I think the increase will have no significance at all. We shouldn't just
"optimize" the code, we should first see WHERE it is slow
then optimize that part. It is well known in programming that you can spend
weeks optimizing code and see NO difference at all
simply because you optimized the wron
Yeah I thought about it, but that's a function that you call about 6 or 7 times per contact. By duplicating code, you don't have to check every times if $para == true or false.That's my point !--
Benjamin[EMAIL PROTECTED]
-
Ta
Hi, instead of duplicating code, wouldn't it be better to use a
boolean parameter to setContactData, to enable or disable the event
thing? This way this parameter would default to TRUE (fire the event),
but when called from loadXMLContact it would be set to false.
Greets.
On 8/6/06, Benjamin <[EM
Hi ! In the file abook.tcl , the proc setContactData on line 340, what about re-create another procedure named « setContactDataFast ». It should be the same that « setContactData » but without the condition « # An event used by guicontactlist to know when a user changed his nick (or state) ». Then