Yes. It has been benchmarked at 100 ms for 7200 glyphs, and
maximum size of a single unit of work. Larger requests can
In short, what you are claiming is that your complete a
request and processing in 1 CPU cycle of context
switching. A quantum is around ~15 ms on
multi-core/processors.
No matter how you configure it, 10 threads in 1
process, 10 processes on 1 machine or across machines,
you need at least 10 handlers to handle the 100 TPS
with 100 ms transaction times.
10 ms transaction time
Unrealistic. Dreaming.
To prove the point, here is a simple code to show it:
#include <windows.h>
void main(int
DWORD t1 = GetTickCount();
Sleep(1); // sleep 1 millisecond
DWORD t2 = GetTickCount();
You will see the t2-t1 is around ~15 ms. Its call a
QUANTUM, your sleeps is in factors of Quantums:
Sleep(16) --> 2 quantums or ~30 ms
Sleep(32) --> 3 quantums or ~45 ms
#include <windows.h>
#include <stdio.h>
void main(char argc, char *argv[])
{
DWORD t1 = GetTickCount();
Sleep(1); // sleep 1 millisecond
DWORD t2 = GetTickCount();
printf("Sleep Efficiency: %d\n",t2-t1);
t1 = GetTickCount();
Sleep(16);
t2 = GetTickCount();
printf("Sleep Efficiency: %d\n",t2-t1);
t1 = GetTickCount();
Sleep(32);
t2 = GetTickCount();
printf("Sleep Efficiency: %d\n",t2-t1);
}
What it means is that in a code that does not do any
preemption on its own (which will slow it down), just
natural code, the CPU and OS will preempt you every
QUANTUM.
I sincerely doubt you can do your OCR processing in less
than 1 QUANTUM yet alone 10 ms.
Now, here's the thing:
If indeed you can achieve processing in less than 1
quantum or even 2 quantums, then you really should not be
worry about anything else because your OCR system would be
among the fast applications in the world!
--
HLS