2018-01-08 10:39 GMT+01:00 Sven Van Caekenberghe <[email protected]>: > > > > On 8 Jan 2018, at 10:30, Pavel Krivanek <[email protected]> > wrote: > > > > In memory sources file > > - I slightly improved the PR for integration of the sources file inside > the object memory. Now it will be possible to extract them back to the disk > from the menu so everything can work as before. I'm not sure if it will be > integrated into Pharo 7 or we will wait for Pharo 8 but it seems to be > prepared. > > > > File API and caching > > - because the in-memory sources file do not use deprecated > MultiByteFileStream, I played with the new file API and discovered that > ZnCharacterReadStream on File is about 10 times slower than the old > MultiByteFileStream. That's because ZnCharacterReadStream does not use any > cache. For better speed the ZnBufferedReadStream needs to be used like this: > > > > readStream := File openForReadFileNamed: 'file.txt'. > > zn := ZnCharacterReadStream on: readStream encoding: #UTF8. > > buffered := ZnBufferedReadStream on: zn. > > [ buffered atEnd ] whileFalse: [ buffered next: 20000 ]. > > Yes, that is correct. > > > However the ZnBufferedReadStream is by design only a linear stream and > the position cannot be changed and thus it cannot be used for *.sources > files etc. We will need to prepare a positionable alternative. > > This is great work, Pavel, I know Marcus wanted this for a loooooong time > ;-) > > Now, I thought (naively maybe) that in memory sources meant that each > method object holds a single (compressed) string with its own individual > source code. In such a system no positioning in a huge stream would (ever) > be necessary, no ? >
I use an implementation that should be more memory efficient and make much less stress for the GC. It uses the old concept of pointers to a sources file but the sources file is a set of compressed segments stored in memory. When all sources compressed as a single file take about 6MB, with compression by segments it takes about 7MB. I expect that for very small methods the compressed version can save no memory at all and you would need a next extra object for every method. -- Pavel > > AFAIK, the need for positioning is only to get to the right source bit in > this huge pool. > > > Ring 2 integration > > - I was working on replacing of the old Ring with the new > reimplementation. The old Ring is used on many sensitive places in the > system. Mainly in tools however it is used by Monticello and Epicea too so > to try to remove it is like to cut a branch below yourself on an undermined > tree. The approach of the old and new Ring is in many senses very different > and the full compatibility will not be supported. I partly provide > compatibility API, partly adopt the code directly. > > - The real system and the model is mixed many times in the users of the > old Ring. For example a model for a method is created but then when the > package of the method is asked, it is already a real package, not its > model. Such places need to be cleaned. > > - I already have an image that has no old Ring code at all but because > of some memory leaks caused by the mixtures of the models and real system I > was not able to bootstrap it successfully. More work is needed. > > - I discovered that the image has a serious memory leak caused by > Iceberg/GT and Announcers but I still need to find more information about > it. > > > > Smalltalk archeology > > - during the free days on the beginning of the year I looked at > Smalltalk-78. I extracted the data from Lively Kernel so the original image > can read from external files, not only the recent updated ones. > > - Then I looked at SqueakJS again and tried to reproduce Craig's > experiments with Pharo on it. Generally it is about 100 times slower than > native Pharo which makes it hard to use for real-life tasks. However it > would be pity to do not provide at least basic attention to it because in > some cases it may be really useful. > > > > Cheers, > > -- Pavel > > > > > > >
