Coro benchmarks ?

[Marc Lehmann]

> > On Fri, Apr 29, 2011 at 09:53:42PM +0200, Przemyslaw Iskra <sparky at pld-linux.org> wrote:
> > > Are there some good benchmarks for coro to test how blocking is some
> > > thread / module / whatever ?
> > 
> > If you ever find a method on how to benchmark some API without knowing it
> > let us know :)
> 
> I was thinking about something like "total running time" vs "time spent
> outside coro idle process", since "cpu time" won't really tell me how
> much did my module take.

Well, you still have to write actual code that calls that API, what you ask
for here is just a timing measurement.

Coro can actually do per-thread timings (see Coro::State::enable_times)
- the real time spent per thread is usually most precise (if you havean
otherwise idle system). The Coro::Debug shell lets you play around with
that interactively.

> > But using AE (I mean the AE:: namespace, not AnyEvent) on the perl level
> > will already gie you the highets speed possible.
> 
> The nice thing about EV that AE does not have is that I can register a
> socket for both reading and writing and it tells me which of those

But AE actually allows you to do the same, and works to great lengths to
even allow that for backends that do not support this themselves, because
I condidfe rit evry important to allow both on the same fd - what problems
did you run into?

> Got that. Furthermore, it is very unlikely for people to have Coro and
> not AnyEvent,

Given that AnyEvent is a dependency of Coro, yeah.

> > OTOH, there already is AnyEvent::Curl and AnyEvent::Curl::Multi - maybe
> > improving WWW::Curl to add timeout functionality and then improving that
> > might be the better way.
> 
> Well, I did that, and sent patches to WWW::Curl maintainer.
> 
> However, I found there was a room for many more improvements, some of
> them incompatible with WWW::Curl, so I rewrote the module almost
> entirely and released as Net::Curl.

That sounds good, I found WWW::Curl to be quite lacking in API coverage.

> Reasonably recent libcurl provides callbacks which notify on socket
> status change and timeout change, while calling them only when
> necessary. This is just perfect for integration with event libraries.

Last I looked, it didn't tell you when the fd stays the same but
the underlying file description changes, which is required for
epoll/kqueue/etc., but I guess this has been changed?

Personally, I stay away from libcurl after running into too many problems
like these, or outright bugs, such as non working proxy support when using
the multi api - all of which is not documented, and very hard to track down,
as all simple uses work fine.

(If not for these I would have written a libcurl interface long ago :)

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\