<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi all!<br/>
@IOhannes, msgfile looks promising, we testet it and it writes really fast.<br/>
<br/>
Regarding iemmatrix: It looks like it is not possible to change the size of matrices dynamically. But we definitely need this functionality.<br/>
<br/>
Hence, our first idea now is to implement a wrapper-abstraction around [msgfile] that works like [coll], so that we hopefully can more or less replace our current [coll] objects with our abstraction within our main patch. One issue that comes into our minds here is that [coll] offers a way of referencing one buffer at different places in a patch. E.g. you can have different [coll myMatrix] objects and they all refer to the same collection of data. We do have various [coll] objects in our patch as well, all of them referencing to the same data matrix. In your opinion, what would be the best approach to implement this referencing-mechanism with [msgfile]?</div>
<div> </div>
<div>Thanks, Hajar and Jakob<br/>
<br/>
<br/>
<br/>
<br/>
Gesendet: Donnerstag, 05. Dezember 2019 um 13:37 Uhr<br/>
Von: "IOhannes m zmoelnig" <zmoelnig@iem.at><br/>
An: pd-list@lists.iem.at<br/>
Betreff: Re: [PD] writing to cyclone/coll takes a long time<br/>
On 30.11.19 14:00, Jakob Laue wrote:<br/>
> Do you have any hint why it takes that long to write 60000 rows into coll? Maybe we do something wrong or have missed some smarter way to write our rows into the coll matrix.<br/>
<br/>
i don't know what you want to do, but if this is about "writing" (to<br/>
file), you could also use zexy's [msgfile].<br/>
<br/>
<br/>
some numbers (on an i7-7700, running Debian/GNU linux, 64bit)<br/>
<br/>
- adding 700 entries: <1ms<br/>
- adding 6000 entries: <11ms<br/>
- adding 60000 entries: <50ms<br/>
- writing 60000 entries to disk: <150ms<br/>
- reading 60000 entries from disk: <130ms<br/>
- output next entry: <1ms<br/>
- seek to entry #20000 <3ms<br/>
<br/>
outputting the "next" entry is O(1).<br/>
seeking to a position, resp, searching an entry is O(n).<br/>
<br/>
<br/>
dfmasdr<br/>
IOhannes<br/>
<br/>
PS: there's also a memory leak that ed.kelly discovered recently, that<br/>
occurs when dealing with long lines. need to put a new version online....<br/>
<br/>
_______________________________________________<br/>
Pd-list@lists.iem.at mailing list<br/>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" target="_blank">https://lists.puredata.info/listinfo/pd-list</a></div></div></body></html>