On Sat, 30 Apr 2005 16:00:40 +0200
 Serassio Guido <[EMAIL PROTECTED]> wrote:
Hi Evgeny,

At 13.05 30/04/2005, Evgeny Kotsuba wrote:
I have removed similar things some time ago from the Windows port for poor performance reasons.
I don't understand this. Really call to read/write/sevd/recv is call to a number of system's API calls and one more call get 0.0001% performance

Experimental results:

old style: 10 - 15 % CPU usage for a 100 MB file transfer
new style: 0.1 - 05 % CPU usage for the same transfer
The CPU was a 1.6 GHz P4
The test was done using MS Visual Studio C++ 6.0, a very bad C++ compiler.
Now the development is made with Visual Studio 2005 Beta 2 (The only MS C++ compiler able to compile Squid 3.0 ....)
Really I don't know if it was a compiler "optimization" problem.


But this is not enough, because don't solve the second problem. Here the solution could be the usage of something like a Squid_Socket class with all socket calls encapsulation.

I am not quite understand problem
I have made:
class squid_fde wich is analog to filedescriptor
and
class squid_fdeArray
{...
squid_fde *fd_table;
....
extern squid_fdeArray squid_fd_table;
with typical usage as squid_fd_table.fd_table[fd] instead of fd_table[fd]


usage of squid_fd_table class may be not very efficient, but very convenient so that it is single place for all filedescriptor's operetion. It is possible to have variable number of fds etc.

Not sure to understand: How you find the right socket handle into the squid_fd_table ? with a for loop search ?


class squid_fde { /* former struct _fde */
int fh; /* real file handle or socket */
public:
unsigned int type;
u_short local_port;
u_short remote_port;
......
class squid_fdeArray
{
public:
int n; /* number of used items in fd_table i.e. analog of Biggest_FD */
int nAllocated; /* allocated siseof fd_table */
int iCurrent; /* current index */
squid_fde *fd_table; /* */
int *SocketToIndex;
/* array for getting index number on socket */


In os/2 there is two limits on socket's number: first is 2048 with so called 16-bit old TCP/IP stack and default 8K with 32-bit TCP/IP stack. But with 32-bit stack there is one more problem: select, macroses FD_XXX, fd_set structure and
#pragma pack(4)
typedef struct fd_set {
u_short fd_count; /* how many are SET? */
int fd_array[FD_SETSIZE]; /* an array of SOCKETs */
} fd_set;
#pragma pack()
and it's usage in comm_select.c(pp)


Nevertheless this it seems solved

Sorry, but I can't understand this last question.

look at comm_select.c(pp) how fd_set without macros FD_XXX is used. It is supposed that fd_set is bitfield that is wrong with structure above.



OT: Evgeny, Do you can take a look into this OS/2 bugzilla ? http://www.squid-cache.org/bugs/show_bug.cgi?id=1040

mmm.. This is for  Squid3 ...   But I really work only with 2.5


SY, Evgeny Kotsuba

Reply via email to