[Insight-developers] type of modification time

[Bradley Lowekamp]

Marius,

I think adding the ModifiedTimeType type is a very good idea. However, I think I would prefer to put this type as a type def of the TimeStamp class.

Adding this type def would make a great first step towards updating this type. I have not looked into the detail of all the atomic operations to know if what you proposed is plausible. But I think you  could make a patch to gerrit with this first step either way. 

I also found this interesting:

$ git grep "GetMTime" | wc -l
     292

300 seems like it may be do able to quickly check the usage of these methods too.

Brad

On Sep 24, 2012, at 9:28 AM, "M.Staring at lumc.nl" <M.Staring at lumc.nl> wrote:

> Hi Brad,
>  
> The std::vector may indeed be a good alternative. I made the filter that uses the itk::VectorContainer a long time ago, and I forgot why I chose one over the other. It is going to be some work for me to change this. I will have a look to guess how much work that will be.
>  
>  
> Regarding the timestamp type. What I thought that could be done is to define a type in itkIntTypes:
> typedef SizeValueType ModifiedTimeType;
> and then use it throughout the toolkit. This way you avoid trickiness across platforms, right?
> That would mean replacing all these unsigned longs in itkTimeStamp.cxx and also in many other classes with ModifiedTimeType. That is also some work of course:
> grep "unsigned long GetMTime" -r * | wc -l
> gives me 21 which is not so bad.
>  
> What do you think of this approach?
>  
> Regards, Marius
>  
> From: Bradley Lowekamp [mailto:blowekamp at mail.nih.gov] 
> Sent: maandag 24 september 2012 15:13
> To: Staring, M. (LKEB)
> Cc: insight-developers at itk.org
> Subject: Re: [Insight-developers] type of modification time
>  
> Hello Marius,
>  
> The modify is a moderately expensive operation, as it evolves a mutex lock or an atomic operation. I think the simplest thing to do is not it to use the VectorContainer for this situation why was this chosen over the stl vector container? Looking at the implementation of the itk::VectorContainer, it looks rather unfortunate that the Modified is called for so many operations, as it really makes it not suitable for many situations.
>  
> As for changing the type to a large integer type, that seems like a good thing to me. The good thing now is that all compilers which ITK supports have the unsigned long long type. The bad news is that if you look at the itkTimeStamp.cxx file there are separate paths for win32, apple and gcc. So there are quite a few paths of code which will need to be implements. It's going to be very tricky to get all the types to match in both 32 and 64 bit builds across the platforms, there there are all the usage of the timestamp which may have a cast. 
>  
> What do you think will be best for you to do?
>  
> Brad
>  
>  
> On Sep 24, 2012, at 7:45 AM, M.Staring at lumc.nl wrote:
> 
> 
> Hi all,
>  
> The type of the modified time in ITK (m_MTime in Object) is itk::TimeStamp which in turn has a member:
>  
> unsigned long m_ModifiedTime;
>  
> So this member can count in the range 0 till ulong max, which is about 4 x 10^9.
>  
> For my particular case this member overflows. I'm using the itk::VectorContainer and every time an item is inserted Modified() is called which increases the unsigned long value. In my case I am using minimal spanning trees and a simple algorithm would have N^2 inserts with N the number of points of the tree, which is about 5000 for my application so 5000^2 = 25 x 10^6. Then I re-use the container in an iterative algorithm, which makes the problem worse. I can do about 85 iterations and then it overflows. (This causes my filter to never update anymore, even if  I explicitly call modified on it, or on the output, or call ResetPipeline().)
>  
> A solution to this issue would be to use an unsigned long long for this variable. From itkIntTypes.h there is the typedef SizeValueType which may be appropriate.
>  
> Before I start preparing a patch: Does this seem like a good approach to you?
>  
> Regards, Marius
>  
> Marius Staring, PhD
> Division of Image Processing (LKEB)
> Department of Radiology
> Leiden University Medical Center
> PO Box 9600, 2300 RC Leiden, The Netherlands
> phone: +31 (0)71 526 2137, fax: +31 (0)71 524 8256
> m.staring at lumc.nl
>  
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
> 
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-developers/attachments/20120924/c0ecddef/attachment.htm>