On Mon, 14 Nov 2011, Kopparapu, Sangeeta (GE Healthcare, consultant) wrote:

> Thank you so much for your response.

Please read up on our netiquette and follow that:
http://curl.haxx.se/mail/etiquette.html

> I did testing on a transfer of 1500 files (created a file with 1500 URLs to
> download and used cat <filename> >> hiper.fifo) and measured time. It is
> around 7 seconds. If I use my easy API code(old/previous code) by launching
> 10 threads, the performance is 1.75 seconds.

That seems a bit weird to me. What resolver backend are you using for example?

> I still haven't replaced epoll API calls in hiperfifo.c and using libevent
> 2.5 version. Are there any other changes/tips you suggest me?

Yes, here's one advice: learn the API and don't just hack in stuff in random
examples/codes. As has already been proven here you could increase your speeds
in the order of magnitudes simply by using the API better. Imagine what you
can do if you actually understood how things work and what your task is at
detail!

> I do not want to use fifo to input my URLs to libCURL. In my current
> architecture , I get list of URLs from upstream(some other module) in the
> form of vector. So, naturally, I do not want to make too many changes to my
> code if I want to go ahead with libCURL hiper API. So, Is there any method
> that libCURL supports which accepts pointer to buffer of URLs?

libcurl only supports URLs given as a single char *, as an argument to
CURLOPT_URL. There is no other way, and frankly I don't quite understand what
other way that would make much sense!

> I would like to know other methods to trigger parallel transfer other than
> fifo.

A fifo does not trigger parallel transfers at all. A fifo is just a
communication pipe that was handy to make the example code. It is just an
example.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html