PR: Compressed sources inside the object memory

Hi,

when the Pharo 7 image is being built on top of the bootstrapped image, all loaded code is placed in the changes file so this process ends with an empty sources file, huge changes file and the image. We condense the sources file for every build so we distribute the Pharo 7 as three files - image, huge sources (over 30 MB) and almost empty changes file.

As consequence every build has own sources file that can be shared between images based on the same build - so when we will release the Pharo 7, the sources file can be shared as it was for previous releases, but as soon as some fixing version of Pharo 7 will be released, it will require a new specific sources file.

As one possible solution I tried to create a pull request that resurrects from oblivion an old code made for Squeak 3.7 that introduced option of compressed sources files. Such files use segments that are stored in compressed form so it is not so small as one single zip file but still good enough. From original uncompressed file of size 30.8 MB it generates 7.1 MB file while single zip has 6.1 MB.

Of course the image file is bigger but:

- the amount of new objects is low so it should not make much more stress on GC

- we already used to have big images because the condenser was not working and it was not a big issue

- the amount of distributed files will be the same as in case of Pharo 6 (image+changes) so it means less troubles

- the sources file can be easily restored, deleted from the object memory and used the same way as before 

- we are not using the nice concept of the image well enough. All data that are not really shared between images or serve as backup information should be stored inside image

Please review this PR. As a side effect it makes the sources file mechanism (but not changes file) independent on the FileStream classes that are deprecated.

PR: https://github.com/pharo-project/pharo/pull/631

The pre-built image:

 https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-631/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-57ddc75.zip

Cheers,

-- Pavel

 

Nice.

2017-12-28 15:50 GMT+01:00 Pavel Krivanek <[hidden email]>:

Hi,

when the Pharo 7 image is being built on top of the bootstrapped image, all loaded code is placed in the changes file so this process ends with an empty sources file, huge changes file and the image. We condense the sources file for every build so we distribute the Pharo 7 as three files - image, huge sources (over 30 MB) and almost empty changes file.

As consequence every build has own sources file that can be shared between images based on the same build - so when we will release the Pharo 7, the sources file can be shared as it was for previous releases, but as soon as some fixing version of Pharo 7 will be released, it will require a new specific sources file.

As one possible solution I tried to create a pull request that resurrects from oblivion an old code made for Squeak 3.7 that introduced option of compressed sources files. Such files use segments that are stored in compressed form so it is not so small as one single zip file but still good enough. From original uncompressed file of size 30.8 MB it generates 7.1 MB file while single zip has 6.1 MB.

Of course the image file is bigger but:

- the amount of new objects is low so it should not make much more stress on GC

And how many objects it adds? (how many sections are compressed?)

 

- we already used to have big images because the condenser was not working and it was not a big issue

- the amount of distributed files will be the same as in case of Pharo 6 (image+changes) so it means less troubles

- the sources file can be easily restored, deleted from the object memory and used the same way as before 

- we are not using the nice concept of the image well enough. All data that are not really shared between images or serve as backup information should be stored inside image

Can we avoid empty changes file? We can create it on demand (when user modifies code for example). 

 

Please review this PR. As a side effect it makes the sources file mechanism (but not changes file) independent on the FileStream classes that are deprecated.

PR: https://github.com/pharo-project/pharo/pull/631

The pre-built image:

 https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-631/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-57ddc75.zip

Cheers,

-- Pavel

 

2017-12-28 16:00 GMT+01:00 Denis Kudriashov <[hidden email]>:

Nice.

2017-12-28 15:50 GMT+01:00 Pavel Krivanek <[hidden email]>:

Hi,

when the Pharo 7 image is being built on top of the bootstrapped image, all loaded code is placed in the changes file so this process ends with an empty sources file, huge changes file and the image. We condense the sources file for every build so we distribute the Pharo 7 as three files - image, huge sources (over 30 MB) and almost empty changes file.

As consequence every build has own sources file that can be shared between images based on the same build - so when we will release the Pharo 7, the sources file can be shared as it was for previous releases, but as soon as some fixing version of Pharo 7 will be released, it will require a new specific sources file.

As one possible solution I tried to create a pull request that resurrects from oblivion an old code made for Squeak 3.7 that introduced option of compressed sources files. Such files use segments that are stored in compressed form so it is not so small as one single zip file but still good enough. From original uncompressed file of size 30.8 MB it generates 7.1 MB file while single zip has 6.1 MB.

Of course the image file is bigger but:

- the amount of new objects is low so it should not make much more stress on GC

And how many objects it adds? (how many sections are compressed?)

It uses currently 1619 segments of size 20000 bytes but that does not mean that such amount of objects is needed because in the memory filesystem all the (compressed) data are in single ByteArray and the stream class uses a very simple segments table - one big array of 1619 integer items that contain indexes to the ByteArray.

 

- we already used to have big images because the condenser was not working and it was not a big issue

- the amount of distributed files will be the same as in case of Pharo 6 (image+changes) so it means less troubles

- the sources file can be easily restored, deleted from the object memory and used the same way as before 

- we are not using the nice concept of the image well enough. All data that are not really shared between images or serve as backup information should be stored inside image

Can we avoid empty changes file? We can create it on demand (when user modifies code for example). 

I think we can because it contains only do-its. We should be able to simply delete it and only modify the image start-up do do not require it.

-- Pavel

 

 

Please review this PR. As a side effect it makes the sources file mechanism (but not changes file) independent on the FileStream classes that are deprecated.

PR: https://github.com/pharo-project/pharo/pull/631

The pre-built image:

 https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-631/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-57ddc75.zip

Cheers,

-- Pavel

 

Interesting to compare speed of search operation like "find string in sources"

2017-12-28 16:21 GMT+01:00 Pavel Krivanek <[hidden email]>:

2017-12-28 16:00 GMT+01:00 Denis Kudriashov <[hidden email]>:

Nice.

2017-12-28 15:50 GMT+01:00 Pavel Krivanek <[hidden email]>:

Hi,

when the Pharo 7 image is being built on top of the bootstrapped image, all loaded code is placed in the changes file so this process ends with an empty sources file, huge changes file and the image. We condense the sources file for every build so we distribute the Pharo 7 as three files - image, huge sources (over 30 MB) and almost empty changes file.

As consequence every build has own sources file that can be shared between images based on the same build - so when we will release the Pharo 7, the sources file can be shared as it was for previous releases, but as soon as some fixing version of Pharo 7 will be released, it will require a new specific sources file.

As one possible solution I tried to create a pull request that resurrects from oblivion an old code made for Squeak 3.7 that introduced option of compressed sources files. Such files use segments that are stored in compressed form so it is not so small as one single zip file but still good enough. From original uncompressed file of size 30.8 MB it generates 7.1 MB file while single zip has 6.1 MB.

Of course the image file is bigger but:

- the amount of new objects is low so it should not make much more stress on GC

And how many objects it adds? (how many sections are compressed?)

It uses currently 1619 segments of size 20000 bytes but that does not mean that such amount of objects is needed because in the memory filesystem all the (compressed) data are in single ByteArray and the stream class uses a very simple segments table - one big array of 1619 integer items that contain indexes to the ByteArray.

 

- we already used to have big images because the condenser was not working and it was not a big issue

- the amount of distributed files will be the same as in case of Pharo 6 (image+changes) so it means less troubles

- the sources file can be easily restored, deleted from the object memory and used the same way as before 

- we are not using the nice concept of the image well enough. All data that are not really shared between images or serve as backup information should be stored inside image

Can we avoid empty changes file? We can create it on demand (when user modifies code for example). 

I think we can because it contains only do-its. We should be able to simply delete it and only modify the image start-up do do not require it.

-- Pavel

 

 

Please review this PR. As a side effect it makes the sources file mechanism (but not changes file) independent on the FileStream classes that are deprecated.

PR: https://github.com/pharo-project/pharo/pull/631

The pre-built image:

 https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-631/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-57ddc75.zip

Cheers,

-- Pavel

 

For string searching in source codes it is 1.5s (external sources) vs 3.7s (in image compressed), for recompilation of the image it was for me 51s vs 56s.

-- Pavel

2017-12-28 17:10 GMT+01:00 Denis Kudriashov <[hidden email]>:

2017-12-28 17:07 GMT+01:00 Denis Kudriashov <[hidden email]>:

Interesting to compare speed of search operation like "find string in sources"

With Calypso you can do it by:

[(ClyMethodSources withString: 'example' from: ClyNavigationEnvironment currentImageScope ) execute] timeToRun

 

2017-12-28 16:21 GMT+01:00 Pavel Krivanek <[hidden email]>:

2017-12-28 16:00 GMT+01:00 Denis Kudriashov <[hidden email]>:

Nice.

2017-12-28 15:50 GMT+01:00 Pavel Krivanek <[hidden email]>:

Hi,

when the Pharo 7 image is being built on top of the bootstrapped image, all loaded code is placed in the changes file so this process ends with an empty sources file, huge changes file and the image. We condense the sources file for every build so we distribute the Pharo 7 as three files - image, huge sources (over 30 MB) and almost empty changes file.

As consequence every build has own sources file that can be shared between images based on the same build - so when we will release the Pharo 7, the sources file can be shared as it was for previous releases, but as soon as some fixing version of Pharo 7 will be released, it will require a new specific sources file.

As one possible solution I tried to create a pull request that resurrects from oblivion an old code made for Squeak 3.7 that introduced option of compressed sources files. Such files use segments that are stored in compressed form so it is not so small as one single zip file but still good enough. From original uncompressed file of size 30.8 MB it generates 7.1 MB file while single zip has 6.1 MB.

Of course the image file is bigger but:

- the amount of new objects is low so it should not make much more stress on GC

And how many objects it adds? (how many sections are compressed?)

It uses currently 1619 segments of size 20000 bytes but that does not mean that such amount of objects is needed because in the memory filesystem all the (compressed) data are in single ByteArray and the stream class uses a very simple segments table - one big array of 1619 integer items that contain indexes to the ByteArray.

 

- we already used to have big images because the condenser was not working and it was not a big issue

- the amount of distributed files will be the same as in case of Pharo 6 (image+changes) so it means less troubles

- the sources file can be easily restored, deleted from the object memory and used the same way as before 

- we are not using the nice concept of the image well enough. All data that are not really shared between images or serve as backup information should be stored inside image

Can we avoid empty changes file? We can create it on demand (when user modifies code for example). 

I think we can because it contains only do-its. We should be able to simply delete it and only modify the image start-up do do not require it.

-- Pavel

 

 

Please review this PR. As a side effect it makes the sources file mechanism (but not changes file) independent on the FileStream classes that are deprecated.

PR: https://github.com/pharo-project/pharo/pull/631

The pre-built image:

 https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-631/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-57ddc75.zip

Cheers,

-- Pavel

 

2017-12-28 20:02 GMT+01:00 Pavel Krivanek <[hidden email]>:

For string searching in source codes it is 1.5s (external sources) vs 3.7s (in image compressed), for recompilation of the image it was for me 51s vs 56s.

I expected much better performance than external file. Can it be optimized?

I guess that every "aMethod sourceCode" decompresses full section. And it can be easily cached.

To measure maximum speed can you check the version with uncompressed inmemory sources? 

 

-- Pavel

2017-12-28 17:10 GMT+01:00 Denis Kudriashov <[hidden email]>:

2017-12-28 17:07 GMT+01:00 Denis Kudriashov <[hidden email]>:

Interesting to compare speed of search operation like "find string in sources"

With Calypso you can do it by:

[(ClyMethodSources withString: 'example' from: ClyNavigationEnvironment currentImageScope ) execute] timeToRun

 

2017-12-28 16:21 GMT+01:00 Pavel Krivanek <[hidden email]>:

2017-12-28 16:00 GMT+01:00 Denis Kudriashov <[hidden email]>:

Nice.

2017-12-28 15:50 GMT+01:00 Pavel Krivanek <[hidden email]>:

Hi,

when the Pharo 7 image is being built on top of the bootstrapped image, all loaded code is placed in the changes file so this process ends with an empty sources file, huge changes file and the image. We condense the sources file for every build so we distribute the Pharo 7 as three files - image, huge sources (over 30 MB) and almost empty changes file.

As consequence every build has own sources file that can be shared between images based on the same build - so when we will release the Pharo 7, the sources file can be shared as it was for previous releases, but as soon as some fixing version of Pharo 7 will be released, it will require a new specific sources file.

As one possible solution I tried to create a pull request that resurrects from oblivion an old code made for Squeak 3.7 that introduced option of compressed sources files. Such files use segments that are stored in compressed form so it is not so small as one single zip file but still good enough. From original uncompressed file of size 30.8 MB it generates 7.1 MB file while single zip has 6.1 MB.

Of course the image file is bigger but:

- the amount of new objects is low so it should not make much more stress on GC

And how many objects it adds? (how many sections are compressed?)

It uses currently 1619 segments of size 20000 bytes but that does not mean that such amount of objects is needed because in the memory filesystem all the (compressed) data are in single ByteArray and the stream class uses a very simple segments table - one big array of 1619 integer items that contain indexes to the ByteArray.

 

- we already used to have big images because the condenser was not working and it was not a big issue

- the amount of distributed files will be the same as in case of Pharo 6 (image+changes) so it means less troubles

- the sources file can be easily restored, deleted from the object memory and used the same way as before 

- we are not using the nice concept of the image well enough. All data that are not really shared between images or serve as backup information should be stored inside image

Can we avoid empty changes file? We can create it on demand (when user modifies code for example). 

I think we can because it contains only do-its. We should be able to simply delete it and only modify the image start-up do do not require it.

-- Pavel

 

 

Please review this PR. As a side effect it makes the sources file mechanism (but not changes file) independent on the FileStream classes that are deprecated.

PR: https://github.com/pharo-project/pharo/pull/631

The pre-built image:

 https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-631/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-57ddc75.zip

Cheers,

-- Pavel

 

2017-12-28 22:29 GMT+01:00 Denis Kudriashov <[hidden email]>:

2017-12-28 20:02 GMT+01:00 Pavel Krivanek <[hidden email]>:

For string searching in source codes it is 1.5s (external sources) vs 3.7s (in image compressed), for recompilation of the image it was for me 51s vs 56s.

I expected much better performance than external file. Can it be optimized?

I guess that every "aMethod sourceCode" decompresses full section. And it can be easily cached.

To measure maximum speed can you check the version with uncompressed inmemory sources? 

Raw memory file has time for searching for a string in the image 2.1s BUT if the file is stored on disk, the time is 16.5s so about 10-times slower than current version. I suppose that the original fast mechanism used MultiByteFileStream but the new mechanism uses ZnCharacterReadStream.

So, in the same conditions the compressed memory stream is almost 5-times faster than disk access. We should try to find some optimization but I think that it is not necessary to do it immediately.

-- Pavel

 

 

-- Pavel

2017-12-28 17:10 GMT+01:00 Denis Kudriashov <[hidden email]>:

2017-12-28 17:07 GMT+01:00 Denis Kudriashov <[hidden email]>:

Interesting to compare speed of search operation like "find string in sources"

With Calypso you can do it by:

[(ClyMethodSources withString: 'example' from: ClyNavigationEnvironment currentImageScope ) execute] timeToRun

 

2017-12-28 16:21 GMT+01:00 Pavel Krivanek <[hidden email]>:

2017-12-28 16:00 GMT+01:00 Denis Kudriashov <[hidden email]>:

Nice.

2017-12-28 15:50 GMT+01:00 Pavel Krivanek <[hidden email]>:

Hi,

when the Pharo 7 image is being built on top of the bootstrapped image, all loaded code is placed in the changes file so this process ends with an empty sources file, huge changes file and the image. We condense the sources file for every build so we distribute the Pharo 7 as three files - image, huge sources (over 30 MB) and almost empty changes file.

As consequence every build has own sources file that can be shared between images based on the same build - so when we will release the Pharo 7, the sources file can be shared as it was for previous releases, but as soon as some fixing version of Pharo 7 will be released, it will require a new specific sources file.

As one possible solution I tried to create a pull request that resurrects from oblivion an old code made for Squeak 3.7 that introduced option of compressed sources files. Such files use segments that are stored in compressed form so it is not so small as one single zip file but still good enough. From original uncompressed file of size 30.8 MB it generates 7.1 MB file while single zip has 6.1 MB.

Of course the image file is bigger but:

- the amount of new objects is low so it should not make much more stress on GC

And how many objects it adds? (how many sections are compressed?)

It uses currently 1619 segments of size 20000 bytes but that does not mean that such amount of objects is needed because in the memory filesystem all the (compressed) data are in single ByteArray and the stream class uses a very simple segments table - one big array of 1619 integer items that contain indexes to the ByteArray.

 

- we already used to have big images because the condenser was not working and it was not a big issue

- the amount of distributed files will be the same as in case of Pharo 6 (image+changes) so it means less troubles

- the sources file can be easily restored, deleted from the object memory and used the same way as before 

- we are not using the nice concept of the image well enough. All data that are not really shared between images or serve as backup information should be stored inside image

Can we avoid empty changes file? We can create it on demand (when user modifies code for example). 

I think we can because it contains only do-its. We should be able to simply delete it and only modify the image start-up do do not require it.

-- Pavel

 

 

Please review this PR. As a side effect it makes the sources file mechanism (but not changes file) independent on the FileStream classes that are deprecated.

PR: https://github.com/pharo-project/pharo/pull/631

The pre-built image:

 https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-631/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-57ddc75.zip

Cheers,

-- Pavel