[ENet-discuss] Multi-threading ENet the easy way...

[Chris Jurney]

There is no way enet can use 20% cpu if used properly on a PC from the last
5 years.  This is something in your usage pattern.  std::vector's overhead
is multiple orders of magnitude too small to bubble up this large.  Blocking
sockets, or excessive polling could both cause this.  Also, check your
bandwidth usage.  If you're streaming megabits through enet, that might
explain it.

On Sun, Feb 7, 2010 at 2:30 PM, Blair Holloway <
thynameisblair at chaosandcode.com> wrote:

> On Fri, Feb 5, 2010 at 7:14 PM, Syed Setia Pernama <syedhs at yahoo.com>wrote:
>
>> I am using Intel VTune profiler and the hits ~20% was in the function
>> enet_protocol_dispatch_incoming_commands.
>> I think the reason why enet is taking much of the processing time because
>> first
>>
>
> To get the obvious out of the way: are your sockets set to non-blocking? If
> they aren't, try that first and see if performance improves.
>
> Since most of your time appears to be spent receiving, having each client
> connected to a separate Enet host, and processing that host in a separate
> thread, seems beneficial.
>
> Since every Enet host will want to listen to a separate socket, will you be
> setting aside a separate Enet host for clients to connect to, that will tell
> the clients the port number of the actual host they should connect to? Or do
> you have some other method of 'jumping' the clients over to a new host?
>
> - Blair
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20100209/e10a6a31/attachment.htm>