[Insight-developers] type of modification time

[M.Staring at lumc.nl]

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<mailto: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<mailto:m.staring at lumc.nl>

_______________________________________________
Powered by www.kitware.com<http://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/efa43338/attachment.htm>