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, "[email protected]" <[email protected]> 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:[email protected]]
> Sent: maandag 24 september 2012 15:13
> To: Staring, M. (LKEB)
> Cc: [email protected]
> 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, [email protected] 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
> [email protected]
>
> _______________________________________________
> 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
>
_______________________________________________
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
