GSL containers (switched sparse format to binary trees)

[Patrick Alken]

This particular thread seems to be more about dynamic allocations of 
gsl_vector inside the multimin routines - I wasn't aware that was 
happening but in theory it should be possible to rewrite things so there 
are no dynamic allocations.

The first thread you linked seems to have a legitimate reason to reduce 
the malloc calls for gsl_vector, since he's allocating a large number of 
small vectors it seems.

Anyway, Gerard, you have a good grasp of the various issues and what 
needs to be done about it - would you be interested in taking the lead 
on this and designing a nice API for user-defined alloc functions?

Patrick

On 05/01/2014 07:55 PM, Gerard Jungman wrote:
> As before, I apologize for the flood of messages.
> But I figure better a few shorter messages than
> one long message with multiple sub-topics.
>
> Here is another discussion that I found interesting:
>
>     http://comments.gmane.org/gmane.comp.lib.gsl.general/4385
>
> As usual, the details could be debated. But I found the
> following quote to be very telling:
>
>    "Rhys, I did try to use views. They do not help because the
>     gsl routines allocate vectors internally and there is not
>     much that I can do about it... except for maybe hacking
>     gsl and changing gsl_vector_alloc myself."
>
> People seem to be led to this conclusion from multiple
> directions.
>
> Another choice quote:
>
>     "The other issue is: the implementation of gsl_vector just
>      seems inefficient to me. Looking at the code, it seems like
>      a single vector requires 3 calls to malloc and free (one for
>      the data, one for the gsl_block, and one for the gsl_vector
>      itself). The manual states that the block is there for
>      "consistency", and I can see how memory management becomes
>      easier with it. But it seems to be a case of generality at
>      the expense of performance. Also, the stride and the owner
>      flag are part of the gsl_vector object to make it work with
>      gsl_views, but then people who never need views pay the
>      performance price anyway."
>
>
>