Anton Bobrov wrote:
Keep in mind that (a) a frequently used function like free() is
likely to be
in the cache, and
it simply doesnt matter if you cache the whole free() + data
or not as amount of cycles in less when spend on simple "if"
check than one or more enter/exit sequences + the same "if"
check. if you utilize or blow instruction/data cache/s or
not by calling free() is another measurement you can add or
sub to/from that but then again it doesnt matter, i simply
did mentioned that to point to the other side of the coin...
In a deeply pipelined architecture, with branch-prediction and
prefetching, it makes less difference than you might assume. We
did heavy instrumentation on this issue when I was at Cisco. The
result was that there was no gain in avoiding calling the function
if the function was heavily used and began with a lightweight test
that returned without doing anything (as in the case of free()).
causes unnecessary bloat... which is an issue in embedded environments
where you don't always have a lot of memory.
(b) duplicating the NULL check done inside free()
which specific embedded environment ? i wouldnt call it
bloat since if you do a build for my mobile phone which
is few years old model it wont notice the difference :)
Settop boxes and hand-helds.
that is bracketed with an unnecessary NULL check.
> I was pointing it out because there are other places that free()
gets called
the point is taken i just reckon we wasting time on this.
i would personally be fine with both takes as it doesnt
really matter that much to make any noticeable difference
imho, i would be more interested if somebody coded some
proper solution for bug 323064 with or without checks for
null pointers to free(). thats all i have to say on this.
Nichivo.
I agree that this bug needs to be fixed.
It just seemed like an opportune time to point out to everyone
reading this that you don't need to check for NULL before
calling free(), as it already does that as part of its defined
behavior, and that when coding future bug fixes this is something
to keep in mind.
-Philip
_______________________________________________
dev-tech-ldap mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-ldap
