About "refactoring"

Original in Russian: http://programmingmindstream.blogspot.ru/2014/09/blog-post_25.html

Based on – Depression, or Falsity of hResult and other ErrorCode

I have found two more “bottlenecks” - AllocNewFATAlement and AllocNewCluster.

They, in turn, lead to LockFile.

That’s because we lock the header that stores the information about warehouse structure.

Another reason is the fact that the header has to be time-accessed.
Otherwise, we’d get a “mess” instead of a “warehouse”.

Users would “bump into these locks”.

I observed such a picture today on “synthetic” load tests.

Under the debugger.

All other machines "sweated guts out”, and I “debugged” one of them.

AND I SAW IT. I really saw it. In the code and on break-point's.

I saw that “one waits for another”.

I already know how to deal with it.

In a lookahead manner, I should allocate not just FATElement and Cluster, but several (five, ten, twenty, thirty) at once.

In one piece.

It is effective in respect that a file usually has more than one, more than two and even ten clusters.

I should also hold the free list at a client site. When a client ends a session, they are returned to the free list – i.e. the list of “not used”, so that other clients could use it too.

It is probable that we lose elements, if the client aborts the process.

But then we get to the “bottleneck” less often, since we can write:

if AllocatedFatElements.Empty then
begin
 // - here we have an interPROCESS “bottleneck”
 Lock;
 try
  Result := AllocNewFatElement;
  for l_Index := 0 to 10 do
   AllocatedFatElements.Add(AllocNewFatElement);
 finally
  Unlock;
 end//try..finally
end
else
 // - here we have ONLY interSTREAM “bottleneck” (because AllocatedFatElements is, naturally, protected from inter-stream)
 Result := AllocatedFatElements.GetLastAndDeleteIt;

Instead of:

Lock;
// - here we ALWAYS have a multiPROCESS “bottleneck”
try
 Result := AllocNewFatElement;
finally
 Unlock;
end;//try..finally

Same for clusters.

Even if elements “hang”, it won’t get worse much, the warehouse won’t be destroyed, it will just have “holes”.

Considering that we have a “night Update” in the night - if possible - the warehouse will anyway be repacked, so the “holes” will disappear “towards morning”.

We’ll get the repacked permanent part without holes and the “empty” variable part.

Clients write their documents versions to the second one during the day.

The next night, the process repeats again.

That is only if there are no signed on users.