Hi Dennis, Zyx
I’d worry that locking introduces performance issues. That one of the reasons
std::string reference counting was dropped in favour of small string
optimization in the C++ standard library (the locks caused a lot of contention
in unexpected places). The reference counting in std::string is also the reason
Visual C++ 6.0 C++ apps weren’t thread safe. There’s more detail here:
http://info.prelert.com/blog/cpp-stdstring-implementations
I think there’s a simpler solution that avoids locking. The design is based on
the HTML5 parser used in Firefox (a long-lived, multi-threaded application). It
has a bunch of pre-defined atoms for HTML element and attribute names like
“html” “body” “div” “href” etc. These corresponds to PdfNames which are defined
in the PDF spec (“kids”, “length” etc)
Does this work:
1) Use a pre-defined name table containing the names of all the PdfNames
defined in the PDF spec (or just the common ones : “Kids”, “P” etc). Once
initialised the name table is read-only so no locking is required to search it.
2) Change TKeyMap from std::map<PdfName,PdfObject*> to
std::map<PdfName*,PdfObject*>
3) When adding an entry to TKeyMap find if it already exists in pre-defined
name table. If it doesn’t dynamically allocate it via new PdfName()
4) There’s no thread contention because names are either global and allocated
at init time, or private and owned by the dictionary (as in PoDoFo currently).
5) Logic for PdfDictionary then becomes something like this
static std::map< std::string, PdfName*> PdfName::s_predefinedNames;
static PdfName()
{
s_predefinedNames[ "Kids" ] = new PdfName(“Kids”);
s_predefinedNames[ "P" ] = new PdfName(“P”);
// etc
};
void PdfDictionary::AddKey( const PdfName & identifier, const PdfObject &
rObject )
{
// snipped parameter checks for brevity
// check if this is a pre-defined name (should account for most/all names
used)
PdfName* pPdfName = s_predefinedNames[ identifier.m_Data ];
if ( pPdfName == NULL )
{
// dynamically allocate name for unknown key which may be an extension
// or from a newer version of PDF than supported by library
pPdfName = new PdfName( identifier );
// delete dyanmically allocated PdfNames - see Clear() below
pPdfName->SetAutoDelete(true);
}
if( m_mapKeys.find( pPdfName ) != m_mapKeys.end() )
{
delete m_mapKeys[pPdfName];
m_mapKeys.erase( pPdfName );
}
m_mapKeys[pPdfName] = new PdfObject( rObject );
m_bDirty = true;
}
void PdfDictionary::Clear()
{
AssertMutable();
if( !m_mapKeys.empty() )
{
TIKeyMap it;
it = m_mapKeys.begin();
while( it != m_mapKeys.end() )
{
// call delete on pPdfNames allocated by AddKey
// but don't delete PdfNames in s_predefinedNames
if (*it).first->GetAutoDelete() )
delete (*it).first;
delete (*it).second;
++it;
}
m_mapKeys.clear();
}
}
Thoughts?
Best Regards
Mark
--
Mark Rogers - mark.rog...@powermapper.com
PowerMapper Software Ltd - www.powermapper.com
Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL
On 14/01/2017, 22:38, "zyx" <z...@litepdf.cz> wrote:
On Sat, 2017-01-14 at 10:19 -0800, Dennis Jenkins wrote:
> If you want a global cache of the PdfNames, I request that you add
> reference counting and protect access with a mutex (or similarly
> appropriate, cross-platform, synchronization barrier).
Hi,
that's precisely what I had on my mind, involving PdfMutex, thus fully
depending on the build options (-DPODOFO_MULTI_THREAD). I can write a
functional code to express in detail, if you'd like to.
Bye,
zyx
--
http://www.litePDF.cz i...@litepdf.cz
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
