Oliver Schulz

It's currently due to design - `ElasticArray` should be contiguous and fast (basically native array speed, except for a slightly more expensive `size`-function). The internal vector reference, kernel size, etc....

Oh, I forgot: One important design criterion is that an `ElasticArray` should be able to "breathe" (grow,shrink,grow,...) without causing a high memory allocation and GC load, to support multithreaded high-throughput...

I did a few tests and it looks like `ElasticArray` might actually be faster (at least sometimes) if it's a mutable struct (expert advice would be very welcome). If ElasticArray...

> I want to change the size of Jacobian matrices but attempt to re-use some of the same memory / not re-allocate the whole thing. I am not sure if...

@timholy: These days Julia's GC is pretty impressive. GC can still quickly become the limiting factor when running on many threads, though, in my experience.

Hmhm - that would require up-front knowledge of the maximum size, right?

Ah, yes - but that would indeed require `kernel_size` to be mutable (currently, `ElasticArray` is immutable). I'm not sure if making `ElasticArray` mutable would be good or bad for performance....

Thanks @alejandroschuler - would you like to try your hand at a PR? It would be nice if we could share as much code as possible between `ElasticArray` and `ExtraFlexArray`...

> I'd like to but I actually only barely know what I'm doing in julia. We'll have a try if you like. :-) I can put this on my to-do...

> Re: naming: can you tell I'm not a software engineer? haha. Yes, preserving backwards compatibility makes sense. No worries! :-) If you're interested, here's some more info on Julia...