views:

81

answers:

4

What should be the preferred way by programmers:

1) Only Write:

SomeBoolean = True

2) Read but write only if necessary

If Not SomeBoolean Then SomeBoolean = True
A: 

Assuming you are referring to a RUNTIME context and a shared variable:

In a multiprocessor environment, unnecessary writes can lead to performance degradation: cache flush, synchronization overhead etc.

So YES it can make a difference... get profiling if the situation lends itself to it.

jldupont
So you say I SOULD make the checking?
Shimmy
Depends on your performance requirements: some might say it is "premature optimization" in cases X,Y,Z whilst in some other cases (e.g. Kernel Drivers) it might be crucial to ascertain the situation.
jldupont
One should also remember that a conditional jump might cost more then the assignment itself (if the variable is in the L1 cache and it's not accessed by other threads frequently). So generally I would suggest not doing such an "optimization" unless logic and/or profiling suggests that the caused cache invalidations are a bottleneck
Grizzly
@Grizzly: another good point.
jldupont
A: 

The difference is negligible. You will see performance differences when reading and writing files to the drive, but program performance is measured in big O. Read:

BIG O notation

Especially in VB you will not see a difference.

JERiv
+2  A: 

It's really hard to know the answer to this without knowing more about the environment. It seems a reasonable check would be to run some performance tests by iterating over this task many, many times.

Empirical evidence sometimes is surprising compared to what you'd expect.

Andrew Flanagan
+1 for recommending testing, and briefly explaining why.
David Thornley
A: 

1) will be maybe a few nanoseconds faster. I suspect that compared to other things going on in your code, that difference is nanoscopic.

On the other hand, I usually write (2) if I might want to do something else when I know that I'm actually changing the boolean. That gives me a place to do it.

Mike Dunlavey