- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by Marcus Denker

On Jul 29, 2013, at 11:29 AM, phil(a)highoctane.be wrote: > Hello, > > I've been loading all of those packages in order to build a full web stack development image. > > Everything now loads fine and kind of works but... > > The image is really slowing down and the size is getting very large. > > Here is the current one: > > 332580684 29 jul 10:50 Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1050.image > > 300+ megs... > Can you try to execute ImageCleaner cleanUpForRelease This way we know if maybe some cache is hanging onto something. > I've been doing some development in there and started looking for why this was getting so large and slow. > > I did a SpaceTally print analysis and imported the results in a spreadsheet. > > Look at the top consumers, especially the Semaphore thing. It is way beyond whatever was expected. There is something wrong there. > > There must be a leak of Points, MorphExtensions and I can't just figure out why there are so many Floats. > MorphExtension should only be referenced by the Morph it extends. So there should always be more Morphs than extensions. This looks really strange. Marcus

July 29, 2013

Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by Mariano Martinez Peck

On Mon, Jul 29, 2013 at 9:02 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > Yes, same for me here. > > I'll update my configuration to load everything in a fresh 2.0 and report > the results. > > Thing is that loading that full configuration takes ages (GlorpDBX is > taking 20 minutes to load...) and the VM gets the SmallInteger bug > triggered with such a large config... > It's easy to fix workaround SmallInteger add issue. Just one line of code in Metacello. And yes, it takes ages. I also build an app that loads Seaside, Magritte3, GlorpDBX, etc and it takes quite a lot. Esteban did something to improve Monticello loading in Pharo 3.0....but that's 3.0, not 2.0... > > I really need to get to grips with what happens down there. > > Phil > > On Monday, July 29, 2013, Sebastian Tleye wrote: > >> Try loading the packages each one at time, and between packages save the >> image and check if it is growing. >> >> >> 2013/7/29 Sebastian Tleye <stleye(a)gmail.com> >> >> What also happened to me, is that, each time i saved the image (even if i >> did nothing), the image was growing its size. >> >> >> 2013/7/29 Sebastian Tleye <stleye(a)gmail.com> >> >> Mmm, so i'm not sure. >> I remember, when i had this problem, i was using directly changeSets, i >> solved the problem doing "FileIn entire file" instead of "Install into a >> new change set" (when you drag a changeset into Pharo). But it was like a >> random bug since i haven't had that problem again (even using "Install into >> a new change set" >> >> >> 2013/7/29 phil(a)highoctane.be <phil(a)highoctane.be> >> >> Hi Sebastian, >> >> No, not intentionally. My code is going into the default change set and >> there isn't that much. >> >> But... when looking at the Changes Sorter, there are indeed a lot of >> entries related to all of those modules (due to the configurations being >> loaded I guess - see screenshots for samples, the list is much longer). >> >> Phil >> >> >> >> >> On Mon, Jul 29, 2013 at 11:39 AM, Sebastian Tleye <stleye(a)gmail.com>wrote: >> >> Hi Phil >> >> Have you been using changeSets? >> I had the same problem once, i couldn't figure out what the problem was, >> but i think there is a problem in the sorter tool (and change sets). >> >> >> >> 2013/7/29 phil(a)highoctane.be <phil(a)highoctane.be> >> >> Hello, >> >> I've been loading all of those packages in order to build a full web >> stack development image. >> >> Everything now loads fine and kind of works but... >> >> The image is really slowing down and the size is getting very large. >> >> Here is the current one: >> >> 332580684 29 jul 10:50 >> Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1050.image >> >> 300+ megs... >> >> I've been doing some development in there and started looking for why >> this was getting so large and slow. >> >> I did a SpaceTally print analysis and imported the results in a >> spreadsheet. >> >> Look at the top consumers, especially the Semaphore thing. It is way >> beyond whatever was expected. There is something wrong there. >> >> There must be a leak of Points, MorphExtensions and I can't just figure >> out why there are so many Floats. >> >> I've been running test suites for some of the packages (e.g. OpenDBX and >> Glorp) and this may be the result. >> >> This image is kind of what one doing web dev would end up with. >> >> But then, it is very hard to get rid of that unwanted space. >> >> I am trying to build a system I can start using for business projects and >> feel concerned about that memory growth very seriously. >> >> Any pointers (I chased some already but here, there are way too many >> entries) >> >> Thx >> >> Phil >> >> >> >> >> > > -- > --- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 > Mail:phil@highoctane.be | Web: http://philippeback.eu > Blog: http://philippeback.be | Twitter: @philippeback > Youtube: http://www.youtube.com/user/philippeback/videos > > High Octane SPRL > rue cour Boisacq 101 | 1301 Bierges | Belgium > > Featured on the Software Process and Measurement Cast > http://spamcast.libsyn.com > Sparx Systems Enterprise Architect and Ability Engineering EADocX Value > Added Reseller > > > > -- Mariano http://marianopeck.wordpress.com

July 29, 2013

Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by phil＠highoctane.be

Yes, same for me here. I'll update my configuration to load everything in a fresh 2.0 and report the results. Thing is that loading that full configuration takes ages (GlorpDBX is taking 20 minutes to load...) and the VM gets the SmallInteger bug triggered with such a large config... I really need to get to grips with what happens down there. Phil On Monday, July 29, 2013, Sebastian Tleye wrote: > Try loading the packages each one at time, and between packages save the > image and check if it is growing. > > > 2013/7/29 Sebastian Tleye <stleye(a)gmail.com> > > What also happened to me, is that, each time i saved the image (even if i > did nothing), the image was growing its size. > > > 2013/7/29 Sebastian Tleye <stleye(a)gmail.com> > > Mmm, so i'm not sure. > I remember, when i had this problem, i was using directly changeSets, i > solved the problem doing "FileIn entire file" instead of "Install into a > new change set" (when you drag a changeset into Pharo). But it was like a > random bug since i haven't had that problem again (even using "Install into > a new change set" > > > 2013/7/29 phil(a)highoctane.be <phil(a)highoctane.be> > > Hi Sebastian, > > No, not intentionally. My code is going into the default change set and > there isn't that much. > > But... when looking at the Changes Sorter, there are indeed a lot of > entries related to all of those modules (due to the configurations being > loaded I guess - see screenshots for samples, the list is much longer). > > Phil > > > > > On Mon, Jul 29, 2013 at 11:39 AM, Sebastian Tleye <stleye(a)gmail.com>wrote: > > Hi Phil > > Have you been using changeSets? > I had the same problem once, i couldn't figure out what the problem was, > but i think there is a problem in the sorter tool (and change sets). > > > > 2013/7/29 phil(a)highoctane.be <phil(a)highoctane.be> > > Hello, > > I've been loading all of those packages in order to build a full web stack > development image. > > Everything now loads fine and kind of works but... > > The image is really slowing down and the size is getting very large. > > Here is the current one: > > 332580684 29 jul 10:50 > Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1050.image > > 300+ megs... > > I've been doing some development in there and started looking for why this > was getting so large and slow. > > I did a SpaceTally print analysis and imported the results in a > spreadsheet. > > Look at the top consumers, especially the Semaphore thing. It is way > beyond whatever was expected. There is something wrong there. > > There must be a leak of Points, MorphExtensions and I can't just figure > out why there are so many Floats. > > I've been running test suites for some of the packages (e.g. OpenDBX and > Glorp) and this may be the result. > > This image is kind of what one doing web dev would end up with. > > But then, it is very hard to get rid of that unwanted space. > > I am trying to build a system I can start using for business projects and > feel concerned about that memory growth very seriously. > > Any pointers (I chased some already but here, there are way too many > entries) > > Thx > > Phil > > > > > -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

July 29, 2013

Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by Sebastian Tleye

Try loading the packages each one at time, and between packages save the image and check if it is growing. 2013/7/29 Sebastian Tleye <stleye(a)gmail.com> > What also happened to me, is that, each time i saved the image (even if i > did nothing), the image was growing its size. > > > 2013/7/29 Sebastian Tleye <stleye(a)gmail.com> > >> Mmm, so i'm not sure. >> I remember, when i had this problem, i was using directly changeSets, i >> solved the problem doing "FileIn entire file" instead of "Install into a >> new change set" (when you drag a changeset into Pharo). But it was like a >> random bug since i haven't had that problem again (even using "Install into >> a new change set" >> >> >> 2013/7/29 phil(a)highoctane.be <phil(a)highoctane.be> >> >> Hi Sebastian, >>> >>> No, not intentionally. My code is going into the default change set and >>> there isn't that much. >>> >>> But... when looking at the Changes Sorter, there are indeed a lot of >>> entries related to all of those modules (due to the configurations being >>> loaded I guess - see screenshots for samples, the list is much longer). >>> >>> Phil >>> >>> >>> >>> >>> On Mon, Jul 29, 2013 at 11:39 AM, Sebastian Tleye <stleye(a)gmail.com>wrote: >>> >>>> Hi Phil >>>> >>>> Have you been using changeSets? >>>> I had the same problem once, i couldn't figure out what the problem >>>> was, but i think there is a problem in the sorter tool (and change sets). >>>> >>>> >>>> >>>> 2013/7/29 phil(a)highoctane.be <phil(a)highoctane.be> >>>> >>>>> Hello, >>>>> >>>>> I've been loading all of those packages in order to build a full web >>>>> stack development image. >>>>> >>>>> Everything now loads fine and kind of works but... >>>>> >>>>> The image is really slowing down and the size is getting very large. >>>>> >>>>> Here is the current one: >>>>> >>>>> 332580684 29 jul 10:50 >>>>> Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1050.image >>>>> >>>>> 300+ megs... >>>>> >>>>> I've been doing some development in there and started looking for why >>>>> this was getting so large and slow. >>>>> >>>>> I did a SpaceTally print analysis and imported the results in a >>>>> spreadsheet. >>>>> >>>>> Look at the top consumers, especially the Semaphore thing. It is way >>>>> beyond whatever was expected. There is something wrong there. >>>>> >>>>> There must be a leak of Points, MorphExtensions and I can't just >>>>> figure out why there are so many Floats. >>>>> >>>>> I've been running test suites for some of the packages (e.g. OpenDBX >>>>> and Glorp) and this may be the result. >>>>> >>>>> This image is kind of what one doing web dev would end up with. >>>>> >>>>> But then, it is very hard to get rid of that unwanted space. >>>>> >>>>> I am trying to build a system I can start using for business projects >>>>> and feel concerned about that memory growth very seriously. >>>>> >>>>> Any pointers (I chased some already but here, there are way too many >>>>> entries) >>>>> >>>>> Thx >>>>> >>>>> Phil >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >

July 29, 2013

Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by Sebastian Tleye

What also happened to me, is that, each time i saved the image (even if i did nothing), the image was growing its size. 2013/7/29 Sebastian Tleye <stleye(a)gmail.com> > Mmm, so i'm not sure. > I remember, when i had this problem, i was using directly changeSets, i > solved the problem doing "FileIn entire file" instead of "Install into a > new change set" (when you drag a changeset into Pharo). But it was like a > random bug since i haven't had that problem again (even using "Install into > a new change set" > > > 2013/7/29 phil(a)highoctane.be <phil(a)highoctane.be> > > Hi Sebastian, >> >> No, not intentionally. My code is going into the default change set and >> there isn't that much. >> >> But... when looking at the Changes Sorter, there are indeed a lot of >> entries related to all of those modules (due to the configurations being >> loaded I guess - see screenshots for samples, the list is much longer). >> >> Phil >> >> >> >> >> On Mon, Jul 29, 2013 at 11:39 AM, Sebastian Tleye <stleye(a)gmail.com>wrote: >> >>> Hi Phil >>> >>> Have you been using changeSets? >>> I had the same problem once, i couldn't figure out what the problem was, >>> but i think there is a problem in the sorter tool (and change sets). >>> >>> >>> >>> 2013/7/29 phil(a)highoctane.be <phil(a)highoctane.be> >>> >>>> Hello, >>>> >>>> I've been loading all of those packages in order to build a full web >>>> stack development image. >>>> >>>> Everything now loads fine and kind of works but... >>>> >>>> The image is really slowing down and the size is getting very large. >>>> >>>> Here is the current one: >>>> >>>> 332580684 29 jul 10:50 >>>> Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1050.image >>>> >>>> 300+ megs... >>>> >>>> I've been doing some development in there and started looking for why >>>> this was getting so large and slow. >>>> >>>> I did a SpaceTally print analysis and imported the results in a >>>> spreadsheet. >>>> >>>> Look at the top consumers, especially the Semaphore thing. It is way >>>> beyond whatever was expected. There is something wrong there. >>>> >>>> There must be a leak of Points, MorphExtensions and I can't just figure >>>> out why there are so many Floats. >>>> >>>> I've been running test suites for some of the packages (e.g. OpenDBX >>>> and Glorp) and this may be the result. >>>> >>>> This image is kind of what one doing web dev would end up with. >>>> >>>> But then, it is very hard to get rid of that unwanted space. >>>> >>>> I am trying to build a system I can start using for business projects >>>> and feel concerned about that memory growth very seriously. >>>> >>>> Any pointers (I chased some already but here, there are way too many >>>> entries) >>>> >>>> Thx >>>> >>>> Phil >>>> >>>> >>>> >>>> >>> >> >

July 29, 2013

Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by Sebastian Tleye

Mmm, so i'm not sure. I remember, when i had this problem, i was using directly changeSets, i solved the problem doing "FileIn entire file" instead of "Install into a new change set" (when you drag a changeset into Pharo). But it was like a random bug since i haven't had that problem again (even using "Install into a new change set" 2013/7/29 phil(a)highoctane.be <phil(a)highoctane.be> > Hi Sebastian, > > No, not intentionally. My code is going into the default change set and > there isn't that much. > > But... when looking at the Changes Sorter, there are indeed a lot of > entries related to all of those modules (due to the configurations being > loaded I guess - see screenshots for samples, the list is much longer). > > Phil > > > > > On Mon, Jul 29, 2013 at 11:39 AM, Sebastian Tleye <stleye(a)gmail.com>wrote: > >> Hi Phil >> >> Have you been using changeSets? >> I had the same problem once, i couldn't figure out what the problem was, >> but i think there is a problem in the sorter tool (and change sets). >> >> >> >> 2013/7/29 phil(a)highoctane.be <phil(a)highoctane.be> >> >>> Hello, >>> >>> I've been loading all of those packages in order to build a full web >>> stack development image. >>> >>> Everything now loads fine and kind of works but... >>> >>> The image is really slowing down and the size is getting very large. >>> >>> Here is the current one: >>> >>> 332580684 29 jul 10:50 >>> Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1050.image >>> >>> 300+ megs... >>> >>> I've been doing some development in there and started looking for why >>> this was getting so large and slow. >>> >>> I did a SpaceTally print analysis and imported the results in a >>> spreadsheet. >>> >>> Look at the top consumers, especially the Semaphore thing. It is way >>> beyond whatever was expected. There is something wrong there. >>> >>> There must be a leak of Points, MorphExtensions and I can't just figure >>> out why there are so many Floats. >>> >>> I've been running test suites for some of the packages (e.g. OpenDBX and >>> Glorp) and this may be the result. >>> >>> This image is kind of what one doing web dev would end up with. >>> >>> But then, it is very hard to get rid of that unwanted space. >>> >>> I am trying to build a system I can start using for business projects >>> and feel concerned about that memory growth very seriously. >>> >>> Any pointers (I chased some already but here, there are way too many >>> entries) >>> >>> Thx >>> >>> Phil >>> >>> >>> >>> >> >

July 29, 2013

Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by phil＠highoctane.be

Hi Sebastian, No, not intentionally. My code is going into the default change set and there isn't that much. But... when looking at the Changes Sorter, there are indeed a lot of entries related to all of those modules (due to the configurations being loaded I guess - see screenshots for samples, the list is much longer). Phil On Mon, Jul 29, 2013 at 11:39 AM, Sebastian Tleye <stleye(a)gmail.com> wrote: > Hi Phil > > Have you been using changeSets? > I had the same problem once, i couldn't figure out what the problem was, > but i think there is a problem in the sorter tool (and change sets). > > > > 2013/7/29 phil(a)highoctane.be <phil(a)highoctane.be> > >> Hello, >> >> I've been loading all of those packages in order to build a full web >> stack development image. >> >> Everything now loads fine and kind of works but... >> >> The image is really slowing down and the size is getting very large. >> >> Here is the current one: >> >> 332580684 29 jul 10:50 >> Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1050.image >> >> 300+ megs... >> >> I've been doing some development in there and started looking for why >> this was getting so large and slow. >> >> I did a SpaceTally print analysis and imported the results in a >> spreadsheet. >> >> Look at the top consumers, especially the Semaphore thing. It is way >> beyond whatever was expected. There is something wrong there. >> >> There must be a leak of Points, MorphExtensions and I can't just figure >> out why there are so many Floats. >> >> I've been running test suites for some of the packages (e.g. OpenDBX and >> Glorp) and this may be the result. >> >> This image is kind of what one doing web dev would end up with. >> >> But then, it is very hard to get rid of that unwanted space. >> >> I am trying to build a system I can start using for business projects and >> feel concerned about that memory growth very seriously. >> >> Any pointers (I chased some already but here, there are way too many >> entries) >> >> Thx >> >> Phil >> >> >> >> >

July 29, 2013

Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by Sebastian Tleye

Hi Phil Have you been using changeSets? I had the same problem once, i couldn't figure out what the problem was, but i think there is a problem in the sorter tool (and change sets). 2013/7/29 phil(a)highoctane.be <phil(a)highoctane.be> > Hello, > > I've been loading all of those packages in order to build a full web stack > development image. > > Everything now loads fine and kind of works but... > > The image is really slowing down and the size is getting very large. > > Here is the current one: > > 332580684 29 jul 10:50 > Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1050.image > > 300+ megs... > > I've been doing some development in there and started looking for why this > was getting so large and slow. > > I did a SpaceTally print analysis and imported the results in a > spreadsheet. > > Look at the top consumers, especially the Semaphore thing. It is way > beyond whatever was expected. There is something wrong there. > > There must be a leak of Points, MorphExtensions and I can't just figure > out why there are so many Floats. > > I've been running test suites for some of the packages (e.g. OpenDBX and > Glorp) and this may be the result. > > This image is kind of what one doing web dev would end up with. > > But then, it is very hard to get rid of that unwanted space. > > I am trying to build a system I can start using for business projects and > feel concerned about that memory growth very seriously. > > Any pointers (I chased some already but here, there are way too many > entries); > > Thx > > Phil > > > >

July 29, 2013

Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by phil＠highoctane.be

Hello, I've been loading all of those packages in order to build a full web stack development image. Everything now loads fine and kind of works but... The image is really slowing down and the size is getting very large. Here is the current one: 332580684 29 jul 10:50 Pharo-DripfeedIt-Magritte3-OpenDBX_20130729_1050.image 300+ megs... I've been doing some development in there and started looking for why this was getting so large and slow. I did a SpaceTally print analysis and imported the results in a spreadsheet. Look at the top consumers, especially the Semaphore thing. It is way beyond whatever was expected. There is something wrong there. There must be a leak of Points, MorphExtensions and I can't just figure out why there are so many Floats. I've been running test suites for some of the packages (e.g. OpenDBX and Glorp) and this may be the result. This image is kind of what one doing web dev would end up with. But then, it is very hard to get rid of that unwanted space. I am trying to build a system I can start using for business projects and feel concerned about that memory growth very seriously. Any pointers (I chased some already but here, there are way too many entries); Thx Phil

July 29, 2013

Re: [Pharo-users] Unix Domain Sockets

by Sven Van Caekenberghe

On 28 Jul 2013, at 17:20, Pierce Ng <pierce(a)samadhiweb.com> wrote: > On Sun, Jul 28, 2013 at 01:12:41PM +0200, Sven Van Caekenberghe wrote: >> Since UDP sockets are currently also in the same class, I don't see a >> need for a separate class in the current design. > > Hi Sven. Agreed, as I wrote in the other mail about gaining experience with > IPv6 as well. OK >> Yes, the code is too cryptic/technical, a helper method or two would >> solve this. > > Done as per my newest blog post. Will add that when I create the issue. Yes, I've seen it. Good, that is what I meant. >>> Also, I'll be looking into the minor changes needed to support >>> SocketStream as well. >> >> Can you elaborate on that ? > > SocketStream has instance creation methods such as > openConnectionToHost:port:. To use Unix domain sockets, I imagine something > like openConnectionToIPCSocketPath:. Ah, OK, I understand. But there is SocketStream class>>#on: once you have your socket. That should be enough for testing client and server side. Once you validated it works, you could indeed add the #openConnectionToIPCSocketPath: convenience method. >> To add this, I would like some minimal tests as well (to be skipped on >> windows). > > I took a peek at SocketTest; the setUp method sets up a server socket, and > tests are run against this socket. This kinda like requires what is being > tested to be working in the first place? I understand your point, it is possible to have interesting theoretical discussions about unit tests, but a test that exercises the code is much better than none at all. If you don't like the setup of SocketTest, write your own test class, like DomainSocketTest. Tests are really important: they are live, validated documentation. Regarding the last blog post, does that mean that a VM change is now necessary or not ? Thanks for contributing ! Sven > Cheers. > > -- > Pierce Ng > http://samadhiweb.com/blog/

July 28, 2013