[Pool] Why is pool allocator slower than ordinary allocator?
Please see this thread on StackOverflow: http://tinyurl.com/chh4yxj Thanks.
Please see this thread on StackOverflow:
Just replied: "FYI Boost.Pool isn't designed for or optimised for that usage - it's designed for lots of fixed-sized blocks, as happens in a list (or even a map or a set), it's not really designed for fast performance with variable sized blocks as happens in a string or a vector." HTH, John.
On Sat, May 5, 2012 at 1:26 PM, John Maddock <boost.regex@virgin.net> wrote: "FYI Boost.Pool isn't designed for or optimised for that usage - it's
designed for lots of fixed-sized blocks, as happens in a list (or even a map or a set), it's not really designed for fast performance with variable sized blocks as happens in a string or a vector."
Do you know of any open-source allocator (available in Boost or elsewhere), that can be used to *quickly* allocate instances of std::wstring, using an allocation pattern like the one showed in the following blog post? http://tinyurl.com/cu3lzwz Thanks, Mr.C64
On Sat, May 5, 2012 at 7:36 AM, Mr.C64 <c64gio@gmail.com> wrote:
On Sat, May 5, 2012 at 1:26 PM, John Maddock <boost.regex@virgin.net> wrote:
"FYI Boost.Pool isn't designed for or optimised for that usage - it's designed for lots of fixed-sized blocks, as happens in a list (or even a map or a set), it's not really designed for fast performance with variable sized blocks as happens in a string or a vector."
Do you know of any open-source allocator (available in Boost or elsewhere), that can be used to *quickly* allocate instances of std::wstring, using an allocation pattern like the one showed in the following blog post?
Thanks, Mr.C64
This is a pretty simple pattern. You could design your own arena allocator for this. Consider a deque std::vector<wchar_t> where each successive vector is some factor larger than the prior. You can just place '\0' delimited strings in that memory, and return it. At the end, when you no longer need your dictionary strings, just clear() your deque. You could go a little lower level for even better performance, but this should already beat the standard allocator by quite a bit. Brian
Hi, I have a sample based on the http server 3 example. I am calling io_service::stop which ends all the threads and the tcp_server's run routine exits. But currently I am not seeing the destructor of the connection being called. It looks like the shared pointers passed to async_read_some are not being freed. Do I need to do something specific the cancel the connection? I am not destroying the server. Markus
...? "Markus Bonk" wrote in message news:jo7vv3$fnk$1@dough.gmane.org... Hi, I have a sample based on the http server 3 example. I am calling io_service::stop which ends all the threads and the tcp_server's run routine exits. But currently I am not seeing the destructor of the connection being called. It looks like the shared pointers passed to async_read_some are not being freed. Do I need to do something specific the cancel the connection? I am not destroying the server. Markus
I have a sample based on the http server 3 example.
I am calling io_service::stop which ends all the threads and the tcp_server's run routine exits. But currently I am not seeing the destructor of the connection being called. It looks like the shared pointers passed to async_read_some are not being freed. Do I need to do something specific the cancel the connection? I am not destroying the server.
After you call io_service::stop(), io_service::run() exits as soon as possible. The handlers are not invoked and not cleared, so all the shared_ptr's embedded into these handlers are sill alive. The handlers will be cleared on ~io_service invocation, as documented: http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/reference/io_servic...
Thank you. I had read that, which is why I mentioned I was not destroying the server. What I want to do is to cap all connections, because say a password has changed. How could I get the io_service to invoke the handlers with a predefined "stop" error? ----------------------------- Markus Bonk Senior Software Engineer 3Dconnexion GmbH Clarita-Bernhard-Str. 18 81249 München Germany Tel: +49 (89) 897 45 42 - 70 Fax: +49 (89) 897 45 42 - 50 mailto:markus_bonk@3dconnexion.com Kennen Sie schon die NEUE SpaceMouse Pro? Hier klicken um mehr zu erfahren! http://www.3dconnexion.de/products/spacemousepro.html?3dxcp=signature_mail Geschaeftsfuehrer: Antonio Pascucci Sitz der Gesellschaft: Muenchen Registergericht: Muenchen HRB 99232 -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Igor R Sent: Wednesday, May 09, 2012 5:35 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [asio] Connection not ending
I have a sample based on the http server 3 example.
I am calling io_service::stop which ends all the threads and the tcp_server's run routine exits. But currently I am not seeing the destructor of the connection being called. It looks like the shared pointers passed to async_read_some are not being freed. Do I need to do something specific the cancel the connection? I am not destroying the server.
After you call io_service::stop(), io_service::run() exits as soon as possible. The handlers are not invoked and not cleared, so all the shared_ptr's embedded into these handlers are sill alive. The handlers will be cleared on ~io_service invocation, as documented: http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/reference/io_servic... _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
After you call io_service::stop(), io_service::run() exits as soon as possible. The handlers are not invoked and not cleared, so all the shared_ptr's embedded into these handlers are sill alive. The handlers will be cleared on ~io_service invocation, as documented: http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/reference/io_servic...
Thank you. I had read that, which is why I mentioned I was not destroying the server. What I want to do is to cap all connections, because say a password has changed. How could I get the io_service to invoke the handlers with a predefined "stop" error?
You can close the relevant sockets, but the handlers won't be called with your custom error code. If I understand your usecase correctly, the right way to go would be to define a state-machine managing your application states, and to communicate between the state-machine and the connection (or some higher level object that encapsulates it). So that, for example, when a password changes, you put the FSM to "unauthenticated" state, and the transition causes the connection to get closed, etc. You can take a look at the examples of Boost.StateChart and Boost.MSM: http://www.boost.org/doc/libs/1_49_0/libs/statechart/doc/tutorial.html http://www.boost.org/doc/libs/1_49_0/libs/msm/doc/HTML/ch03s02.html#d0e334
I don't really see how this changes things. The handlers which io_service has, has shared_ptrs to the connection so to get rid of the connection I need to get the io_service to call the handler so that the shared_ptr gets destroyed, or am I missing something? "Igor R" wrote in message news:CAPnv1PKBNRTPfXwArj4YyKt1hxKYEP4-cPvtD6yQNZAz8KNG1w@mail.gmail.com...
After you call io_service::stop(), io_service::run() exits as soon as possible. The handlers are not invoked and not cleared, so all the shared_ptr's embedded into these handlers are sill alive. The handlers will be cleared on ~io_service invocation, as documented: http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/reference/io_servic...
Thank you. I had read that, which is why I mentioned I was not destroying the server. What I want to do is to cap all connections, because say a password has changed. How could I get the io_service to invoke the handlers with a predefined "stop" error?
You can close the relevant sockets, but the handlers won't be called with your custom error code. If I understand your usecase correctly, the right way to go would be to define a state-machine managing your application states, and to communicate between the state-machine and the connection (or some higher level object that encapsulates it). So that, for example, when a password changes, you put the FSM to "unauthenticated" state, and the transition causes the connection to get closed, etc. You can take a look at the examples of Boost.StateChart and Boost.MSM: http://www.boost.org/doc/libs/1_49_0/libs/statechart/doc/tutorial.html http://www.boost.org/doc/libs/1_49_0/libs/msm/doc/HTML/ch03s02.html#d0e334
I don't really see how this changes things. The handlers which io_service has, has shared_ptrs to the connection so to get rid of the connection I need to get the io_service to call the handler so that the shared_ptr gets destroyed, or am I missing something?
Yes, after you close the socket, all the relevant handlers will be invoked and disposed.
I am still not there yet. To close the socket I need to keep a reference/shared_ptr to the connection somewhere. Which basically means I have two shared_ptrs. If a handler reports an error the connection needs to know something about the manager/state machine/whatever to tell it it is closing down, right? "Igor R" wrote in message news:CAPnv1PKuZ5kDbif8Z73V2RePhYb7e5Oth4ZuF8sW7+NYLgvNaw@mail.gmail.com...
I don't really see how this changes things. The handlers which io_service has, has shared_ptrs to the connection so to get rid of the connection I need to get the io_service to call the handler so that the shared_ptr gets destroyed, or am I missing something?
Yes, after you close the socket, all the relevant handlers will be invoked and disposed.
I am still not there yet. To close the socket I need to keep a reference/shared_ptr to the connection somewhere. Which basically means I have two shared_ptrs. If a handler reports an error the connection needs to know something about the manager/state machine/whatever to tell it it is closing down, right?
Yes, right. Well, if you're speaking of "http server 3" specifically, you have to change its design a bit. Eg., you can add to the server class something like vector<weak_ptr<connection> > connections_ member, and push there every new_connectio_ -- to get an ability of managing connections. Of course, you have to garbage-collect expired weak-ptrs sometimes, eg. when a new connection is added or on some other event...
Thanks Igor "Igor R" wrote in message news:CAPnv1PKnkw=8P7EUhatC5qo=TEaBmrLFF+k_XYSkDmQ3QMV8QQ@mail.gmail.com...
I am still not there yet. To close the socket I need to keep a reference/shared_ptr to the connection somewhere. Which basically means I have two shared_ptrs. If a handler reports an error the connection needs to know something about the manager/state machine/whatever to tell it it is closing down, right?
Yes, right. Well, if you're speaking of "http server 3" specifically, you have to change its design a bit. Eg., you can add to the server class something like vector<weak_ptr<connection> > connections_ member, and push there every new_connectio_ -- to get an ability of managing connections. Of course, you have to garbage-collect expired weak-ptrs sometimes, eg. when a new connection is added or on some other event...
participants (5)
-
Brian Budge -
Igor R -
John Maddock -
Markus Bonk -
Mr.C64