Store Publish Speed VW7.7 -- very slow ...
Locked
12
12
Store Publish Speed VW7.7 -- very slow ...
 
|
This was a topic that crept into another post I had re memory-size
during publish on VW7.7. I noted a few things during a publish ... It was a publish of a bundle containing perhaps 50 or more packages, each containing from 20 to 50 classes. There were changes to one method in one class. The publish reacted as follows - put the new progress thing on top of my publish window - sat there for maybe 30 seconds (that's normal) - then echoed every class name to the Transcript. I don't think that was me doing that because we don't use "Transacript show...", we have an "echo" method in Object, and it was not invoked -- note that only one class of 1000's was changed, but it seemed that every class name appeared in the trascript. - the above took about 1/2 of the time - then it sat quietly doing "things" with just the bundle name in the progress thing The overall was much longer than normal -- 4x? 5x? I cannot measure at this point, but others echo my feeling of 4x ro 5x or more longer than it was under VW7.6 -- Dennis Smith +1 416.798.7948 Cherniak Software Development Corporation Fax: +1 416.798.0948 509-2001 Sheppard Avenue East [hidden email] Toronto, ON M2J 4Z8 sip:[hidden email] Canada http://www.CherniakSoftware.com Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
Ah, now that's very interesting. Echoing all the class names
to the Transcript sounds like what it does when it creates a parcel. So
is it publishing binary? That would certainly slow things down. And we
have had one other report of it publishing things binary when it wasn't
expected, for which we haven't yet been able to figure out why it's
happening. And one of the things that 7.7 does do is default to the
previous binary/source setting. So if you publish something binary, it
will default to publishing it binary in future publishes.
At 10:39 PM 2010-02-18, Dennis Smith wrote: This was a topic that crept into another post I had re memory-size --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
Well - we don't seem to have any "binarySave" flags set in the publish
UI or any of its "items".
However, the transcript write is occurring in methods invoked from "prepareBinarySaveFor:". We are publishing from our own subclass of "PublishPundleDialog" -- the stack dump is attached. On 2/19/2010 8:28 AM, Alan Knight wrote: Ah, now that's very interesting. Echoing all the class names to the Transcript sounds like what it does when it creates a parcel. So is it publishing binary? That would certainly slow things down. And we have had one other report of it publishing things binary when it wasn't expected, for which we haven't yet been able to figure out why it's happening. And one of the things that 7.7 does do is default to the previous binary/source setting. So if you publish something binary, it will default to publishing it binary in future publishes. -- Dennis Smith +1 416.798.7948 Cherniak Software Development Corporation Fax: +1 416.798.0948 509-2001 Sheppard Avenue East [hidden email] Toronto, ON M2J 4Z8 <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@... Canada http://www.CherniakSoftware.com Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
StackTrace.txt (106K)
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
Dennis:
> Well - we don't seem to have any "binarySave" flags set in the publish UI or any of its "items". > > However, the transcript write is occurring in methods invoked from "prepareBinarySaveFor:". > We are publishing from our own subclass of "PublishPundleDialog" -- the stack dump is attached. Yes, the flag isn't set, but for some reason, the package has #binFile not nil, and that causes the the packages to be saved binary in: prepareBinarySaveFor: aPundle aPundle withAllContainedItems do: [:each | (each isPackage and: [each binFile notNil]) ifTrue: [each parcel ifNil: [ | parcelRecord | parcelRecord := StoreParcelRecord from: each storeModel. each storeModel parcelInto: parcelRecord. each basicParcel: parcelRecord]]] The above in effect says that if the binFile accessor answers anything other than nil, THAT is what triggers the save binary. The question is, is there any code in your PublishPundleDialog subclass that might be setting that on the packages? And So It Goes Sames ______________________________________________________________________ Samuel S. Shuster [|] VisualWorks Engineering, Store Project Smalltalk Enables Success -- What Are YOU Using? _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
In reply to this post by Dennis smith-4
Dennis, et al.:
Dennis kindly sent me a private message with the following (please excuse me): > I DO see that if you create a new Package binFile gets set to '' and not nil?? And this caused a major YIKES moment for me! In the method Store.Package class>>newNamed: newNamed: aName "Create a record for a package. Put the name and the time stamp. Do not install the package in the database." | newDBPackage | newDBPackage := super newNamed: aName. newDBPackage binFile: ''. ^newDBPackage That next to last line needs to be deleted!!!! This is a nasty bug, particularly in the world we are in with 7.7 where both old Store and Store.Glorp objects are in the system. So, if you use your own code to create Store.Package objects instead of using Store.Glorp.StorePackage objects, and then eventually pass them along to the new publish mechanism, Boom Goes The Dynamite! I'm putting this in as a Critical AR, and passing this along to Support so they can help too. And So It Goes Sames ______________________________________________________________________ Samuel S. Shuster [|] VisualWorks Engineering, Store Project Smalltalk Enables Success -- What Are YOU Using? _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
Sames
If you are going to delete the next to last line then it looks to me like you can delete the entire method. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Samuel S. Shuster > Sent: Friday, February 19, 2010 3:17 PM > To: Dennis Smith > Cc: VWNC, ; Alan Knight > Subject: Re: [vwnc] Store Publish Speed VW7.7 -- very slow ... > > Dennis, et al.: > > Dennis kindly sent me a private message with the following (please excuse me): > > > I DO see that if you create a new Package binFile gets set to '' and not nil?? > > And this caused a major YIKES moment for me! > > In the method Store.Package class>>newNamed: > > newNamed: aName > "Create a record for a package. > Put the name and the time stamp. > Do not install the package in the database." > > | newDBPackage | > newDBPackage := super newNamed: aName. > newDBPackage binFile: ''. > ^newDBPackage > > That next to last line needs to be deleted!!!! > > This is a nasty bug, particularly in the world we are in with 7.7 where both old Store and Store.Glorp > objects are in the system. > > So, if you use your own code to create Store.Package objects instead of using Store.Glorp.StorePackage > objects, and then eventually pass them along to the new publish mechanism, Boom Goes The Dynamite! > > I'm putting this in as a Critical AR, and passing this along to Support so they can help too. > > And So It Goes > Sames > ______________________________________________________________________ > > Samuel S. Shuster [|] > VisualWorks Engineering, Store Project > Smalltalk Enables Success -- What Are YOU Using? > > > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
In reply to this post by Samuel S. Shuster-2
On 19/02/2010 3:16 PM, Samuel S. Shuster wrote:
Bugs happen -- even Windows 95 had a bug, I know, it made headlines in the local newspaper "BUG FOUND IN WINDOWS 95" :) What's important is the concentration that was put on this, and the speed with which we found it -- great! > Dennis, et al.: > > Dennis kindly sent me a private message with the following (please excuse me): > > >> I DO see that if you create a new Package binFile gets set to '' and not nil?? >> > And this caused a major YIKES moment for me! > > In the method Store.Package class>>newNamed: > > newNamed: aName > "Create a record for a package. > Put the name and the time stamp. > Do not install the package in the database." > > | newDBPackage | > newDBPackage := super newNamed: aName. > newDBPackage binFile: ''. > ^newDBPackage > > That next to last line needs to be deleted!!!! > > This is a nasty bug, particularly in the world we are in with 7.7 where both old Store and Store.Glorp objects are in the system. > > So, if you use your own code to create Store.Package objects instead of using Store.Glorp.StorePackage objects, and then eventually pass them along to the new publish mechanism, Boom Goes The Dynamite! > > I'm putting this in as a Critical AR, and passing this along to Support so they can help too. > > And So It Goes > Sames > ______________________________________________________________________ > > Samuel S. Shuster [|] > VisualWorks Engineering, Store Project > Smalltalk Enables Success -- What Are YOU Using? > > > > > -- Dennis Smith +1 416.798.7948 Cherniak Software Development Corporation Fax: +1 416.798.0948 509-2001 Sheppard Avenue East [hidden email] Toronto, ON M2J 4Z8 sip:[hidden email] Canada http://www.CherniakSoftware.com Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
In reply to this post by Terry Raymond
Terry:
> If you are going to delete the next to last line then > it looks to me like you can delete the entire method. Yes indeed. In the next 7.8 build it will be deleted, but for the 7.7 patch and support and stuff like that, it is/was easier to make a file in that just removed the line. For smarties, removing the method will do the trick ;) And So It Goes Sames ______________________________________________________________________ Samuel S. Shuster [|] VisualWorks Engineering, Store Project Smalltalk Enables Success -- What Are YOU Using? _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
In reply to this post by Samuel S. Shuster-2
One final (I hope) question on this -- is it true then that we now have
packages in the store DB which have binFile set to not-nil so that they will continue to think that they need to dump binary?? If so, how do we go about fixing that?? On 19/02/2010 3:16 PM, Samuel S. Shuster wrote: > Dennis, et al.: > > Dennis kindly sent me a private message with the following (please excuse me): > > >> I DO see that if you create a new Package binFile gets set to '' and not nil?? >> > And this caused a major YIKES moment for me! > > In the method Store.Package class>>newNamed: > > newNamed: aName > "Create a record for a package. > Put the name and the time stamp. > Do not install the package in the database." > > | newDBPackage | > newDBPackage := super newNamed: aName. > newDBPackage binFile: ''. > ^newDBPackage > > That next to last line needs to be deleted!!!! > > This is a nasty bug, particularly in the world we are in with 7.7 where both old Store and Store.Glorp objects are in the system. > > So, if you use your own code to create Store.Package objects instead of using Store.Glorp.StorePackage objects, and then eventually pass them along to the new publish mechanism, Boom Goes The Dynamite! > > I'm putting this in as a Critical AR, and passing this along to Support so they can help too. > > And So It Goes > Sames > ______________________________________________________________________ > > Samuel S. Shuster [|] > VisualWorks Engineering, Store Project > Smalltalk Enables Success -- What Are YOU Using? > > > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > -- Dennis Smith +1 416.798.7948 Cherniak Software Development Corporation Fax: +1 416.798.0948 509-2001 Sheppard Avenue East [hidden email] Toronto, ON M2J 4Z8 sip:[hidden email] Canada http://www.CherniakSoftware.com Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
In reply to this post by Samuel S. Shuster-2
I'm seeing class names on my transcript too when publishing, so I guess I am publishing binary too. That would explain why small publishes are slower than they used to be. I have no store customization whatsoever, just the standard stuff. How do we fix this for already created packages?
Mike Mike Hales Engineering Manager KnowledgeScape www.kscape.com On Fri, Feb 19, 2010 at 1:59 PM, Samuel S. Shuster <[hidden email]> wrote: Terry: _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
In reply to this post by Dennis smith-4
Dennis:
> One final (I hope) question on this -- is it true then that we now have > packages in the store DB which have binFile set to not-nil so that they > will continue to think that they need to dump binary?? If so, how do we > go about fixing that?? I suppose I should have expected that... And the answer is yes, they may. Here is a general script using the new Glorp objects to fix this for ALL such packages in your database: | session query | session := Store.Glorp.StoreLoginFactory currentStoreSession. query := Glorp.Query readManyOf: Store.Glorp.StorePackage where: [:each | each binFile notNil]. packages := session execute: query. "Here you might select for packages not named 'AT Parser Compiler' and others you want to keep binary publishing" "Something like ... packages := packages reject: [:each | 'some reason to not update these']" packages do: [:eachPackage session inUnitOfWorkDo: [session register: eachPackage. eachPackage previous: eachPackage previous. eachPackage binFile: nil]]. session reset Now, you may wonder why there is that line in there: eachPackage previous: eachPackage previous. The reason is I don't remember if a Fix was in 7.7 for automatically filling in this value. It hurts nothing, but if the fix it isn't there, the parent/trace versions get lost. Now for some limited additional help... : query := Query readManyOf: Store.Glorp.StorePackage where: [:each | each parcel notNil]. binarySavedPackages := session execute: query. This will give you all of the packages that HAVE been saved binary in your Database. Further if you then do something like uniqueBinarySavedNames := binarySavedPackages inject: Set new into: [:sum :each | sum add: each name. sum]. With that, you might be able to put together some kind of reject or whatever based on the packages or names to feed to the final update step. Just trying to be helpful. And So It Goes Sames ______________________________________________________________________ Samuel S. Shuster [|] VisualWorks Engineering, Store Project Smalltalk Enables Success -- What Are YOU Using? _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
Thanks!
On 2/19/2010 5:15 PM, Samuel S. Shuster wrote: > Dennis: > > >> One final (I hope) question on this -- is it true then that we now have >> packages in the store DB which have binFile set to not-nil so that they >> will continue to think that they need to dump binary?? If so, how do we >> go about fixing that?? >> > > I suppose I should have expected that... And the answer is yes, they may. > > Here is a general script using the new Glorp objects to fix this for ALL such packages in your database: > > | session query | > session := Store.Glorp.StoreLoginFactory currentStoreSession. > query := Glorp.Query readManyOf: Store.Glorp.StorePackage where: [:each | each binFile notNil]. > packages := session execute: query. > "Here you might select for packages not named 'AT Parser Compiler' and others you want to keep binary publishing" > "Something like ... packages := packages reject: [:each | 'some reason to not update these']" > packages do: > [:eachPackage > session inUnitOfWorkDo: > [session register: eachPackage. > eachPackage previous: eachPackage previous. > eachPackage binFile: nil]]. > session reset > > Now, you may wonder why there is that line in there: > eachPackage previous: eachPackage previous. > > The reason is I don't remember if a Fix was in 7.7 for automatically filling in this value. It hurts nothing, but if the fix it isn't there, the parent/trace versions get lost. > > Now for some limited additional help... : > > query := Query readManyOf: Store.Glorp.StorePackage where: [:each | each parcel notNil]. > binarySavedPackages := session execute: query. > > This will give you all of the packages that HAVE been saved binary in your Database. > > Further if you then do something like > > uniqueBinarySavedNames := binarySavedPackages > inject: Set new > into: > [:sum :each | > sum add: each name. > sum]. > > With that, you might be able to put together some kind of reject or whatever based on the packages or names to feed to the final update step. > > Just trying to be helpful. > > And So It Goes > Sames > ______________________________________________________________________ > > Samuel S. Shuster [|] > VisualWorks Engineering, Store Project > Smalltalk Enables Success -- What Are YOU Using? > > > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > -- Dennis Smith +1 416.798.7948 Cherniak Software Development Corporation Fax: +1 416.798.0948 509-2001 Sheppard Avenue East [hidden email] Toronto, ON M2J 4Z8 sip:[hidden email] Canada http://www.CherniakSoftware.com Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
In reply to this post by Mike Hales
Mike:
> I'm seeing class names on my transcript too when publishing, so I guess I am publishing binary too. That would explain why small publishes are slower than they used to be. I have no store customization whatsoever, just the standard stuff. How do we fix this for already created packages? First look at the message I sent just a moment ago to Dennis too. Then, the question is, do you know which packages you DO want to keep Binary? If the answer is none, just run the script as is, it will do the right thing. Otherwise, you might come up with a collection of package names you want to keep publishing binary... In that case, in the middle of the script you might have: namesToKeep := #('ThisPackage' 'ThatPackage). packages := packages reject: [:each | namesToKeep includes: each name]. just before the: packages do: [:eachPackage ... in the main script. Hope that helps... I wish I had a better automagic solution, so the best I got is making it as E-Z for you to limit the updates if needed. And So It Goes Sames ______________________________________________________________________ Samuel S. Shuster [|] VisualWorks Engineering, Store Project Smalltalk Enables Success -- What Are YOU Using? _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
In reply to this post by Mike Hales
Sames had a script for that, but I'd also like to know why
you're seeing this. And in particular, if it's an artifact from
publishing from old versions, or if there's something happening that puts
it into that state. So if you don't mind, and you don't expect to ever
publish binary, try putting a "anObject ifTrue: [self halt]"
into the method StorePackage>>binFile:, and if it comes up, post
the stack. And even better, save the image in that state somewhere so we
can ask you questions about it.
At 04:51 PM 2010-02-19, Mike Hales wrote: I'm seeing class names on my transcript too when publishing, so I guess I am publishing binary too. That would explain why small publishes are slower than they used to be. I have no store customization whatsoever, just the standard stuff. How do we fix this for already created packages? --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
In reply to this post by Samuel S. Shuster-2
Dear Sames,
> Now, you may wonder why there is that line in there: > eachPackage previous: eachPackage previous. > The reason is I don't remember if a Fix was in 7.7 for > automatically filling in this value. It hurts nothing, > but if the fix it isn't there, the parent/trace versions > get lost. Just FYI, yes, it was fixed in 7.7, in AR 58699 "Fields with default values will overwrite values if they haven't changed in the current unit of work". As well as Glorp tests, a Store-specific test is in the latest StoreForGlorpReplicationTests, #testNoDefaultFieldValueOverwriteOfTrace. The line remains essential in 7.6 and earlier (and does no harm in 7.7, of course). Yours faithfully Niall Ross >Dennis: > > > >>One final (I hope) question on this -- is it true then that we now have >>packages in the store DB which have binFile set to not-nil so that they >>will continue to think that they need to dump binary?? If so, how do we >>go about fixing that?? >> >> > > >I suppose I should have expected that... And the answer is yes, they may. > >Here is a general script using the new Glorp objects to fix this for ALL such packages in your database: > > | session query | > session := Store.Glorp.StoreLoginFactory currentStoreSession. > query := Glorp.Query readManyOf: Store.Glorp.StorePackage where: [:each | each binFile notNil]. > packages := session execute: query. > "Here you might select for packages not named 'AT Parser Compiler' and others you want to keep binary publishing" > "Something like ... packages := packages reject: [:each | 'some reason to not update these']" > packages do: > [:eachPackage > session inUnitOfWorkDo: > [session register: eachPackage. > eachPackage previous: eachPackage previous. > eachPackage binFile: nil]]. > session reset > >Now, you may wonder why there is that line in there: > eachPackage previous: eachPackage previous. > >The reason is I don't remember if a Fix was in 7.7 for automatically filling in this value. It hurts nothing, but if the fix it isn't there, the parent/trace versions get lost. > >Now for some limited additional help... : > > query := Query readManyOf: Store.Glorp.StorePackage where: [:each | each parcel notNil]. > binarySavedPackages := session execute: query. > >This will give you all of the packages that HAVE been saved binary in your Database. > >Further if you then do something like > > uniqueBinarySavedNames := binarySavedPackages > inject: Set new > into: > [:sum :each | > sum add: each name. > sum]. > >With that, you might be able to put together some kind of reject or whatever based on the packages or names to feed to the final update step. > >Just trying to be helpful. > > And So It Goes > Sames >______________________________________________________________________ > >Samuel S. Shuster [|] >VisualWorks Engineering, Store Project >Smalltalk Enables Success -- What Are YOU Using? > > > > > >_______________________________________________ >vwnc mailing list >[hidden email] >http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
In reply to this post by Dennis smith-4
OK, I think I have a theory on this. It seems to me that
what's happening is that older versions do in fact publish with binFile
as an empty string, but that StoreGlorp publishing publishes with it as
nil. So we didn't observe this behaviour internally because we had
switched over to publishing using StoreGlorp well before the feature to
continue publishing something binary if it was previously published that
way went in. So almost everything had been published using the new
mechanism in the meantime. But someone who received 7.7, and loaded a
package which had not been updated using a Storp version, then it would
appear to our code as if it had been published binary previously, and it
would attempt to do so again.
So I suspect we can both provide a patch such that it would check more carefully if something had been published binary, and an expression that would clean up the repository by removing that invalid indicator from any suspect packages. But we need to check the theory. At 05:20 PM 2010-02-19, Dennis Smith wrote: Thanks! --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
In reply to this post by Dennis smith-4
Also, I'll mention that I tried reconciling a package that
didn't have any binary publish issues against 7.6 and 7.7 and it took
almost exactly the same time, so I'll conjecture that issues there are
also related to binary publish. It's one small example, so it could be
wrong, but it seems plausible.
At 05:20 PM 2010-02-19, Dennis Smith wrote: Thanks! --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
In reply to this post by Dennis smith-4
It doesn’t seem that loading or reconciling an old package
with binFile = '' would cause binary publishes in 7.7. I’ve gone
through our repository, and nothing is being published binary: the only packages
with parcel nonNil are from several years ago. Everything published before 7.7
has binFile = ''. Everything published from 7.7 has binFile = nil –
including all the 7.7. base, which was reconciled with the 7.6 versions (which
had binFile = ''), and the couple of dozen new versions of our own packages,
which had been loaded into 7.7 from the 7.6 packages (which had binFile = ''). I haven’t removed the binFile: '' line from Package
class>>newNamed:. We don’t have Store customization, other than
automating base reconcile and loads with something like this: vwVersions := #('7.7' '7.6' '7.5' '7.4.1' '7.4' '7.3.1' '7.3'
'7.2.1' '7.2' '7.1' '7.0' '5i.4' '5i.3' '5i.2'). Store.Registry allPundlesSorted do: [:pundleModel | | dbVersion
| dbVersion
:= (pundleModel class databaseClass allVersionsWithName: pundleModel name)
detect: [:package | vwVersions includes: package version] ifNone: []. dbVersion
notNil ifTrue: [dbVersion
getImagePundle reconcileWithDbVersion: dbVersion]]. orderedNameVersionDict do: [:pundleName :pundleVersion | Store.Package
loadWithName: pundleName version: pundleVersion]. Steve From: [hidden email]
[mailto:[hidden email]] On Behalf Of Alan Knight OK, I think I have a theory on this. It seems to me that
what's happening is that older versions do in fact publish with binFile as an
empty string, but that StoreGlorp publishing publishes with it as nil. So we
didn't observe this behaviour internally because we had switched over to
publishing using StoreGlorp well before the feature to continue publishing
something binary if it was previously published that way went in. So almost
everything had been published using the new mechanism in the meantime. But
someone who received 7.7, and loaded a package which had not been updated using
a Storp version, then it would appear to our code as if it had been published
binary previously, and it would attempt to do so again. Thanks! -- Alan Knight [|], Engineering Manager, Cincom Smalltalk _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
Were you seeing lists of class names go by when publishing?
I think the only way that would happen is if it were publishing binary.
If you weren't, then you might just be seeing slowdowns from the ODBC
issue, and not be affected by the binary publishing issue. Is it still
slow for you with that fix in place? Also, have you run the update77
script which generates a number of additional indexes? That should
improve the speed of some operations considerably. It might slow down
publishing slightly, as the database has to update the indexes, but I
don't think that would account for the kind of symptoms people have
described, or even be likely to be noticeable.
At 04:44 AM 2010-02-25, Steven Kelly wrote: It doesnt seem that loading or reconciling an old package with binFile = '' would cause binary publishes in 7.7. Ive gone through our repository, and nothing is being published binary: the only packages with parcel nonNil are from several years ago. Everything published before 7.7 has binFile = ''. Everything published from 7.7 has binFile = nil including all the 7.7. base, which was reconciled with the 7.6 versions (which had binFile = ''), and the couple of dozen new versions of our own packages, which had been loaded into 7.7 from the 7.6 packages (which had binFile = ''). --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Store Publish Speed VW7.7 -- very slow ...
|
|
In reply to this post by Dennis smith-4
I'm afraid I don't remember
what I (or our script) was doing when the list of just class names
appeared. I certainly wasn't publishing binary, since there are no binary
packages in the last few years in our repository.
When I
unloaded RBBrowserUI, the Transcript was filled with many lines saying the
source from various other classes or packages had been saved - rather odd since
that package was empty.
I'm not seeing speed problems since my ODBC
buffer size fix.
I haven't run the update77 script, because
we still use 7.6, 7.4.1 and maybe even 7.1; the docs weren't clear as to whether
running update77 would be a good idea in that case. Is it?
Steve From: Alan Knight [mailto:[hidden email]] Sent: Thu 25/02/2010 21:13 To: Steven Kelly; Samuel S. Shuster Cc: [hidden email] Subject: RE: [vwnc] Store Publish Speed VW7.7 -- very slow ... Were you seeing lists of class names go by when publishing? I
think the only way that would happen is if it were publishing binary. If you
weren't, then you might just be seeing slowdowns from the ODBC issue, and not be
affected by the binary publishing issue. Is it still slow for you with that fix
in place? Also, have you run the update77 script which generates a number of
additional indexes? That should improve the speed of some operations
considerably. It might slow down publishing slightly, as the database has to
update the indexes, but I don't think that would account for the kind of
symptoms people have described, or even be likely to be noticeable.
At 04:44 AM 2010-02-25, Steven Kelly wrote: It doesn’t seem that loading or reconciling an old package with binFile = '' would cause binary publishes in 7.7. I’ve gone through our repository, and nothing is being published binary: the only packages with parcel nonNil are from several years ago. Everything published before 7.7 has binFile = ''. Everything published from 7.7 has binFile = nil – including all the 7.7. base, which was reconciled with the 7.6 versions (which had binFile = ''), and the couple of dozen new versions of our own packages, which had been loaded into 7.7 from the 7.6 packages (which had binFile = ''). --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |