🚀 go-pugleaf

"Arnie Mauer" <xxx@nowhere.net> wrote in message news:<40227029$1@newsgroups.borland.com>...
> Thanks for your thoughts Bill
> 
> "BillT" <billtouch_no_spam@att.net> wrote in message
> news:4021a124$1@newsgroups.borland.com...
> > Memory allocation is a very likely suspect. If that doesn't prove out,
>  there
> > are a number of performance profilers to help pinpoint the exact nature of
>  the
> > delays.
> 
> I got an evaluation of SmartHEAP SMP but we haven't tried it yet.  Code
> freeze for our spring release is tomorrow, 2/6, and things have been pretty
> hectic.  We allocate almost all of our memory into pools up front so there's
> very little done after that.  However, I can't tell what's going on under
> the covers with WinSock and ADOExpress/ADO/OLEDB.
> 
> We have a profiler, AQTime.  It helps to point out inefficiencies in
> functions but doesn't help with thread contention.
> 
> > Another place to look is any synchronization between threads. Where on a
> > single processor, there may be no contention for any resources because
> > everything is single threaded, in a multiprocessor environment, one thread
>  may
> > end up having to wait on another thread to release a common resource thus
> > less throughput. Identifying these things unfortunately must be done
>  manually
> > by someone who can live and breathe threads.
> 
> What you say is true.  For example, ADO is not thread safe and so we must
> syncronize threads that use these components.  Even so, I can't understand
> why the app actually runs slower on an SMP machine than on a single
> processor box.  I tend to think the problem is really with the memory
> allocation.
> 
> In any case, we have enough performance for the moment and we have to get
> this release out.  We'll probably get back to in in late March or April
> 
> Thanks again,
> 
> - Arnie


One way to determine if it's really thread contention in the memory
allocation routines is to look at the a stack trace from some of the
individual threads. By examinning the stack trace and you determine
that the threads are in malloc and/or free then you DO HAVE thread
contention in the allocation functions. This will definately kill your
scalability. Smart heap is one answer. ESA from cherrystone software
is another answer. Hoard is yet another answer. ALl will solve your
problem. Before choosing though, run benchmarks on your application
and watch the speed and/or memory usage and choose  the right memory
allocation library for your application. Hoard tends to utilize less
memory than either ESA or smartheap, but is slower and not as
scalable. ESA tends to be much faster than smartheap, and in many
cases, but not all, utilizes less memory than smartheap. But, your
mileage may vary. Thats why you need to benchmark.



--
Dave
davearnette@comcast.net