Hi,
I want to use HDF5 Packet Tables for my application. But, before giving it a
try I would like to ask whoever have used it, are there any performance /
API issues with packet table? I'll go for C APIs as I find it good for my
application.
The only problem with the APIs I know is, the API to create variable length
data is not available for packet table in the release 1.8.5 the one which
I'm using right now.
Thanks in Advance.
···
-----
Best Regards,
Santosh
--
View this message in context: http://hdf-forum.184993.n3.nabble.com/Perfromance-issues-with-Packet-Table-tp1903029p1903029.html
Sent from the hdf-forum mailing list archive at Nabble.com.
Hi Santosh.
1) If you look at the cpp dll with dependency viewer (or similar), it's
clear that the binary release of the cpp layer for packet table does NOT
include the variable length class; so you'd have to build the source - VL
packet table class is switched out by VLPT_REMOVED being NOT defined (quirky
name, but there you go), see the H5PacketTable.h file. I haven't checked out
the C dll, but it might suffer the same problem.
2) Regarding performance, I've only used it in anger really when writing
files. The main factor that affects performance is compression. My
application processes a proprietary file, generating an HDF5 file containing
several thousand packet tables. For an example proprietary file of size
100MB, with compression effort 0, processing time is 440 seconds. Same file,
same code, but with compression disabled (-1) when declaring the packet
table object, improves time to 34 seconds - i.e. over 10 times faster for a
change of 1 character in my source code ....
So my approach is to disable compression, since client's can always zip the
resultant file if they wish.
Steve
···
--
View this message in context: http://hdf-forum.184993.n3.nabble.com/Performance-issues-with-Packet-Table-tp1903029p1904312.html
Sent from the hdf-forum mailing list archive at Nabble.com.
IIRC, the variable length Packet Table is disabled by default because it has some serious memory leak issues.
Scott
···
-----Original Message-----
From: hdf-forum-bounces@hdfgroup.org [mailto:hdf-forum-bounces@hdfgroup.org]
On Behalf Of Steve Bissell
Sent: Monday, November 15, 2010 8:25 AM
To: hdf-forum@hdfgroup.org
Subject: Re: [Hdf-forum] Performance issues with Packet Table?
Hi Santosh.
1) If you look at the cpp dll with dependency viewer (or similar), it's
clear that the binary release of the cpp layer for packet table does NOT
include the variable length class; so you'd have to build the source - VL
packet table class is switched out by VLPT_REMOVED being NOT defined (quirky
name, but there you go), see the H5PacketTable.h file. I haven't checked out
the C dll, but it might suffer the same problem.
2) Regarding performance, I've only used it in anger really when writing
files. The main factor that affects performance is compression. My
application processes a proprietary file, generating an HDF5 file containing
several thousand packet tables. For an example proprietary file of size
100MB, with compression effort 0, processing time is 440 seconds. Same file,
same code, but with compression disabled (-1) when declaring the packet
table object, improves time to 34 seconds - i.e. over 10 times faster for a
change of 1 character in my source code ....
So my approach is to disable compression, since client's can always zip the
resultant file if they wish.
Steve
--
View this message in context: http://hdf-
forum.184993.n3.nabble.com/Performance-issues-with-Packet-Table-
tp1903029p1904312.html
Sent from the hdf-forum mailing list archive at Nabble.com.
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.
