Re: How to make GNU Guile more successful

[Freja Nordsiek]

Oh, sorry, just realized I skipped the main question.

There are various data type substitutions that can help or hurt. Replacing 
lists with vectors or vice versa can significantly help or hurt performance 
depending on the use case. Same for charsets vs strings. In situations where 
the data is preserved from collection by other means, weak references to that 
data might reduce the GC load since there is just less data to go through (not 
sure how the GC implements weak references so could be very worng about that).


Freja Nordsiek

On July 16, 2017 12:39:20 PM GMT+02:00, Freja Nordsiek <address@hidden> wrote:
>Not necessarily. Using bytevectors and SRFI-4 vectors works very well
>for some kinds of data. Just, they aren't the best for other kinds (in
>principle they can work with all data if one is one implements a heap
>or other custom memory management inside one). They can be made to work
>but are hard for some types of data, and if you are working with
>pointers inside them very easy to get a segfault (even python numpy,
>which has a lot of work done on it over many years, still has a fairly
>easy way to segfault it if one uses object dtype).
>
>
>Freja Nordsiek
>
>On July 16, 2017 12:31:37 PM GMT+02:00, Marko Rauhamaa
><address@hidden> wrote:
>>Freja Nordsiek <address@hidden>:
>>
>>> I checked the implementation of bytecectors and SRFI-4 in Guile and
>>> they are definitely not scanned for pointers. But I would say
>hacking
>>> them is not a good general solution for this problem. They are good
>>> and natural data structures for large arrays of numerical data that
>>> are standard signed/unsigned integers of various fixed sizes and
>IEEE
>>> floating point numbers, or structures/unions of these types. Using
>>> them for things other than that or strings/byte-arrays could be
>error
>>> prone, messy, and performance poor.
>>
>>So no Scheme solution recommended then?
>>
>>
>>Marko