Hi guys,
I am just wondering if there could be a primitive or something that I could use to print YYYYMMDD of a DateAndTime in a faster way than #printYMDOn: |
Mariano, Sorry, no primitives ... some Smalltalk hackery might shave a bit of time off the calculations ... What kind of operations are you doing where you need this? If it is a generic problem we might consider creating a primitive...
Dale On Wed, Jun 11, 2014 at 8:31 AM, Mariano Martinez Peck <[hidden email]> wrote:
|
On Wed, Jun 11, 2014 at 12:52 PM, Dale Henrichs <[hidden email]> wrote:
Hi Dale, My scenario is not very fancy....I just have a domain class which is a typical transaction (bank or investment). I may have LOTS of them...by lot I mean a couple of millions maybe. Then, I have a form in which a field is an "associated transaction". I have an seaside / jquery autocomplete component. As part of the "label" I show, I show the transaction date (which is internal a DateAndTime..but for displaying date is ok). And this is where I need to print the yyyymmdd of the DateAndTime.
A similar scenario is that the above list has to also be sorted. The label I use to display the autocomplete list is composed from 5 different fields (one is the dateandtime). So right now I have a #printInfoString or whatever, and I sort the collection using that string instead of a sorblock that checks for many fields. And yes...here the DateAndTime printYMDOn: takes a large % of the time because it is called many many times...
Best,
Mariano http://marianopeck.wordpress.com |
Mariano,
Does the printing of the DateAndTime invoke TimeZoneInfo>>transitionAtLocal: ? I cannot check right now, but I remember we optimized this method with a cache because we also noticed slow behavior when dealing with a lot of DateAndTime printing (or arithmetic). What basically happens is that the timezone transition date is being looked up every time to determine the local time. Since those dates never change, a cache takes it away. Obviously, I will share the code. But it would be interesting if you can check in the meantime if this method is being called by printing the DateAndTime in your app. Also, check out the DateTime class if you want to build indexes on DateTime in Gemstone. See the indexes section of the manual: they are optimized in the indexes. Johan On 11 Jun 2014, at 18:28, Mariano Martinez Peck <[hidden email]> wrote: > > > > On Wed, Jun 11, 2014 at 12:52 PM, Dale Henrichs <[hidden email]> wrote: > Mariano, > > Sorry, no primitives ... some Smalltalk hackery might shave a bit of time off the calculations ... > > What kind of operations are you doing where you need this? If it is a generic problem we might consider creating a primitive... > > > Hi Dale, > > My scenario is not very fancy....I just have a domain class which is a typical transaction (bank or investment). I may have LOTS of them...by lot I mean a couple of millions maybe. Then, I have a form in which a field is an "associated transaction". I have an seaside / jquery autocomplete component. As part of the "label" I show, I show the transaction date (which is internal a DateAndTime..but for displaying date is ok). And this is where I need to print the yyyymmdd of the DateAndTime. > > A similar scenario is that the above list has to also be sorted. The label I use to display the autocomplete list is composed from 5 different fields (one is the dateandtime). So right now I have a #printInfoString or whatever, and I sort the collection using that string instead of a sorblock that checks for many fields. And yes...here the DateAndTime printYMDOn: takes a large % of the time because it is called many many times... > > Best, > > > Dale > > > On Wed, Jun 11, 2014 at 8:31 AM, Mariano Martinez Peck <[hidden email]> wrote: > Hi guys, > > I am just wondering if there could be a primitive or something that I could use to print YYYYMMDD of a DateAndTime in a faster way than #printYMDOn: > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com |
If the goal is to sort, then why not use DateAndTime>>#’asSeconds’ rather than converting it to a String?
On Jun 11, 2014, at 9:46 AM, Johan Brichau <[hidden email]> wrote: > Mariano, > > Does the printing of the DateAndTime invoke TimeZoneInfo>>transitionAtLocal: ? > > I cannot check right now, but I remember we optimized this method with a cache because we also noticed slow behavior when dealing with a lot of DateAndTime printing (or arithmetic). > What basically happens is that the timezone transition date is being looked up every time to determine the local time. Since those dates never change, a cache takes it away. > > Obviously, I will share the code. > But it would be interesting if you can check in the meantime if this method is being called by printing the DateAndTime in your app. > > Also, check out the DateTime class if you want to build indexes on DateTime in Gemstone. See the indexes section of the manual: they are optimized in the indexes. > > Johan > > On 11 Jun 2014, at 18:28, Mariano Martinez Peck <[hidden email]> wrote: > >> >> >> >> On Wed, Jun 11, 2014 at 12:52 PM, Dale Henrichs <[hidden email]> wrote: >> Mariano, >> >> Sorry, no primitives ... some Smalltalk hackery might shave a bit of time off the calculations ... >> >> What kind of operations are you doing where you need this? If it is a generic problem we might consider creating a primitive... >> >> >> Hi Dale, >> >> My scenario is not very fancy....I just have a domain class which is a typical transaction (bank or investment). I may have LOTS of them...by lot I mean a couple of millions maybe. Then, I have a form in which a field is an "associated transaction". I have an seaside / jquery autocomplete component. As part of the "label" I show, I show the transaction date (which is internal a DateAndTime..but for displaying date is ok). And this is where I need to print the yyyymmdd of the DateAndTime. >> >> A similar scenario is that the above list has to also be sorted. The label I use to display the autocomplete list is composed from 5 different fields (one is the dateandtime). So right now I have a #printInfoString or whatever, and I sort the collection using that string instead of a sorblock that checks for many fields. And yes...here the DateAndTime printYMDOn: takes a large % of the time because it is called many many times... >> >> Best, >> >> >> Dale >> >> >> On Wed, Jun 11, 2014 at 8:31 AM, Mariano Martinez Peck <[hidden email]> wrote: >> Hi guys, >> >> I am just wondering if there could be a primitive or something that I could use to print YYYYMMDD of a DateAndTime in a faster way than #printYMDOn: >> >> Thanks in advance, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com > |
In reply to this post by Johan Brichau-3
On Wed, Jun 11, 2014 at 1:46 PM, Johan Brichau <[hidden email]> wrote: Mariano, Hi Johan,
No, my code does not call that method, but thanks for the heads up anyway.
Mariano http://marianopeck.wordpress.com |
In reply to this post by James Foster-9
On Wed, Jun 11, 2014 at 2:13 PM, James Foster <[hidden email]> wrote: If the goal is to sort, then why not use DateAndTime>>#’asSeconds’ rather than converting it to a String? Because....I am afraid of writing the correct sort block ;) The thing is like this... this domain model object has approx. 3 to 5 fields that are the ones I used for both: 1) displaying a string (the one I use to display in the autocomplete), 2) and using that string to sort them.
So...why I am using that string with the 5 fields for sorting? Well...because some of those fields may be nil. And they are 3 to 5 fields to sort by. So with the string it is very very easy because I simply concatenate a whole string with the fields in order and hence the sort works at the string level. Ideally... (if faster), I would really like to make a proper sortBlock. But...do you imagine how a sortBlock would look like when sorting by 5 fields and from which some of them may be nil? I do not even dare to write it hahahahhahaha.
Does GemStone provide some capacity to easily sort collections over multiple fields? yeah...reading the dev guide now... Thanks
Mariano http://marianopeck.wordpress.com |
On Jun 11, 2014, at 10:23 AM, Mariano Martinez Peck <[hidden email]> wrote:
Why not implement #’<=‘ in your domain object? If this is a specialized sort then the method could be #’forPurposesOfDisplaySortsBeforeOrEqualTo:’ James
|
Administrator
|
In reply to this post by Mariano Martinez Peck
So...why I am using that string with the 5 fields for sorting? Well...because some of those fields may be nil. And they are 3 to 5 fields to sort by. So with the string it is very very easy because I simply concatenate a whole string with the fields in order and hence the sort works at the string level. Sorting is at best O(n log n). DO NOT do conversions to determine the sort order. Your performance is guaranteed to be pathological. If you must use the print strings, create a cache mapping the DateAndTime instances to the string representation and look up the value. Use an IdentityDictionary. Performance will still suffer, but not nearly as badly, since you will not have billions and billions of object creations occurring. On Wed, Jun 11, 2014 at 10:23 AM, Mariano Martinez Peck <[hidden email]> wrote:
|
There are many places where I may have made boneheaded performance related mistakes . Other than experience, is there a reference for a set of 'don't do this and if you are stop and fix it right now' tips? I know to measure first and then start fixing, but I'm afraid I've reached a local maxima because I have ... unrefined ... technique. |
In reply to this post by Mariano Martinez Peck
Why not adding an extra instVar for the YYYYMMDD String. Gerhard On Wed, Jun 11, 2014 at 5:31 PM, Mariano Martinez Peck <[hidden email]> wrote:
|
Dare i mention dynamicInstVarAt: and dynamicInstVarAt:put:? On Wed, Jun 11, 2014 at 12:46 PM, Gerhard Obermann <[hidden email]> wrote:
|
In reply to this post by Gerhard Obermann
Hi guys, Yes, I first was going to add an extra instVar for the yyyymmdd but then it would need to be reset whenever any of the associated fields was changed. So I went with the solution Richard suggested...just keep a IdentityDictionary as a cache where keys are the original objects and values are the sort string. Then I sort them using the cache. Something like this:
autocompleteFilterBlock: [ :options :queryString | | filteredOptions cache | filteredOptions := OrderedCollection new.
cache := IdentityDictionary new. options do: [ :each | | printInfoString |
(each notNil and: [(printInfoString := each printInfoString) matches: queryString]) ifTrue: [ cache at: each put: printInfoString ]
]. cache keys sorted: [:a :b | (cache at: a) <= (cache at: b) ] ];
So far these works good enough for my current needs. Later I may want a proper implementation of #<= or a sortBlock that deals with all my fields and be nil tolerant. And yeah, I can even reuse the same dict/cache for each filter call...
Thank guys, On Wed, Jun 11, 2014 at 4:46 PM, Gerhard Obermann <[hidden email]> wrote:
Mariano http://marianopeck.wordpress.com |
Hi Mariano,
Ive written a few sort blocks with multiple keys before. They are messy... very messy when you get beyond 4-5 keys. no way around it. but in your case of dealing with nil, the thing you need to ask, is simply -- will the 'nil' sort to the top of the list, or the bottom?. Then you can construct your sort block accordingly. I recommend generating yourself some test data, and then take an iterative approach. 1 key, 2 keys, 3 keys... etc, until you get to the length you want. Or if you want to send me some data outside the list i can take a stab at it. On Wed, Jun 11, 2014 at 12:56 PM, Mariano Martinez Peck <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |