[Cdash] ITK appears in GDCM cdash

[David Cole]

The goal of the feature is to only store identical test output once. The
same exact test output is submitted day after day after day after day by
dashboard clients that run the same tests every day.

Perhaps sticking with crc32, but also using 'projectid' and testname as
select criteria would be a better strategy than simply relying on the crc32
alone.


On Thu, Sep 3, 2009 at 11:31 AM, Amitha Perera <amitha.perera at kitware.com>wrote:

> On Thu, Sep 3, 2009 at 9:41 AM, David Cole<david.cole at kitware.com> wrote:
> > Julien's not only worried about the speed of the SQL query. He's also
> (and
> > probably more) worried about the speed of computing the hash on large
> input
> > data (test output ranges from a few bytes up to several megabytes
> depending
> > on the test...)
>
> If computation speed is an issue, and the goal is to simply check if
> the test has been previously submitted, I'd suggest that a
> hierarchical scheme should be used with lazy hash computation, instead
> of relying on a hash as the one-and-only solution. Something like
>
> For each incoming submission I
>   Cand = select * from DB where date=I.date and project=I.project and
> (other such simple things)
>   I.hash=NULL;
>   if Cand is not empty
>     I.hash = hash(I);
>     for each C in Cand
>        if C.hash is null
>            C.hash = hash(C);
>            store C.hash in DB;
>        end if
>        if C.hash == I.hash
>           ignore I and jump to next submission
>        end if
>     end for
>   end if
>   insert I into DB;
> end for
>
> I suspect that hashes would not need to be computed very often.
> (Unless it's common place for the same test to be submitted multiple
> times?)
>
> Anyway, Eric's suggestion of a different, faster to compute hash is
> also a good one.
>
> Amitha.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cdash/attachments/20090903/b665f70e/attachment-0003.htm>