Re: [fpc-devel] Faster InitObject
Am 23.02.2012 08:47 schrieb Amir a...@aavani.net:
Hi,
I have a code, developed in object pascal, with many classes. The
project is working fine.
Today, I used callgrind (valgrind --tool=calgrind) to see which
function consumes the most execution time and I noticed that the most of
time in my project is consumed by fillchar function.
Incl. Self. Called Function
29.78 29.7226MSYSTEM_FILLCHAR$formal$INT64$BYTE
19.07 19.07123M SYSTEM_MOVE$formal$formal$INT64
3.633.6370M SYSTEM_SYSGETMEM_FIXED$QWORD$$POINTER
The main caller of FillChar function is
system_TObject_$__NewInstance$$TObject which called Fillchar 26 Million
times.
NewInstance method in TObject calls InitInstance which is an inline
function and defined as follows:
class function TObject.InitInstance(instance : pointer) :
tobject; {$ifdef SYSTEMINLINE} inline; {$ENDIF}
begin
{ the size is saved at offset 0 }
fillchar(instance^, InstanceSize, 0);
{ insert VMT pointer into the new created memory area }
{ (in class methods self contains the VMT!) }
ppointer(instance)^:=pointer(self);
if PVmt(self)^.vIntfTable @emptyintf then
InitInterfacePointers(self,instance);
InitInstance:=TObject(Instance);
end;
My question is do we need to call fillchar in InitInstance? Or Is there
any way to avoid calling InitInstance?
Yes, FillChar is needed, because a class instance is guaranteed to have
Bennett initialized with zero before the first constructor is called (this
way the fields are basically initialized by 0, Nil or '' depending on the
field type).
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Faster InitObject
Am 23.02.2012 09:27 schrieb Sven Barth pascaldra...@googlemail.com: Yes, FillChar is needed, because a class instance is guaranteed to have Bennett initialized with zero before the first constructor is called (this way the fields are basically initialized by 0, Nil or '' depending on the field type). Sometimes I hate my phone's autocompletion: it should have been been instead of Bennett... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Faster InitObject
Incl. Self. Called Function
29.78 29.7226MSYSTEM_FILLCHAR$formal$INT64$BYTE
19.07 19.07123M SYSTEM_MOVE$formal$formal$INT64
3.633.6370M SYSTEM_SYSGETMEM_FIXED$QWORD$$POINTER
The main caller of FillChar function is
system_TObject_$__NewInstance$$TObject which called Fillchar 26 Million
times.
NewInstance method in TObject calls InitInstance which is an inline
function and defined as follows:
class function TObject.InitInstance(instance : pointer) :
tobject; {$ifdef SYSTEMINLINE} inline; {$ENDIF}
begin
{ the size is saved at offset 0 }
fillchar(instance^, InstanceSize, 0);
{ insert VMT pointer into the new created memory area }
{ (in class methods self contains the VMT!) }
ppointer(instance)^:=pointer(self);
if PVmt(self)^.vIntfTable @emptyintf then
InitInterfacePointers(self,instance);
InitInstance:=TObject(Instance);
end;
My question is do we need to call fillchar in InitInstance? Or Is there
any way to avoid calling InitInstance?
Yes, FillChar is needed, because a class instance is guaranteed to
have Bennett initialized with zero before the first constructor is
called (this way the fields are basically initialized by 0, Nil or ''
depending on the field type).
But still...
Any improvement done in the Creating and Freeing an Objects would be
welcome :)
We need the FillChar there, but if the object creation could be
optimized even a little bit, it would benefit almost all the code. Some
more than others... But still...
-Tee-
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Faster InitObject
In our previous episode, Tommi Prami said: depending on the field type). But still... Any improvement done in the Creating and Freeing an Objects would be welcome :) Usually pooling the most used objecttype(s) is already enough. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Faster InitObject
Am 23.02.2012 10:05, schrieb Tommi Prami:
Incl. Self. Called Function
29.78 29.72 26M SYSTEM_FILLCHAR$formal$INT64$BYTE
19.07 19.07 123M SYSTEM_MOVE$formal$formal$INT64
3.63 3.63 70M SYSTEM_SYSGETMEM_FIXED$QWORD$$POINTER
The main caller of FillChar function is
system_TObject_$__NewInstance$$TObject which called Fillchar 26 Million
times.
NewInstance method in TObject calls InitInstance which is an inline
function and defined as follows:
class function TObject.InitInstance(instance : pointer) :
tobject; {$ifdef SYSTEMINLINE} inline; {$ENDIF}
begin
{ the size is saved at offset 0 }
fillchar(instance^, InstanceSize, 0);
{ insert VMT pointer into the new created memory area }
{ (in class methods self contains the VMT!) }
ppointer(instance)^:=pointer(self);
if PVmt(self)^.vIntfTable @emptyintf then
InitInterfacePointers(self,instance);
InitInstance:=TObject(Instance);
end;
My question is do we need to call fillchar in InitInstance? Or Is there
any way to avoid calling InitInstance?
Yes, FillChar is needed, because a class instance is guaranteed to
have Bennett initialized with zero before the first constructor is
called (this way the fields are basically initialized by 0, Nil or ''
depending on the field type).
But still...
Any improvement done in the Creating and Freeing an Objects would be
welcome :)
We need the FillChar there, but if the object creation could be
optimized even a little bit, it would benefit almost all the code. Some
more than others... But still...
In August 2010 Florian already said that maybe FillChar should be
optimized:
http://lists.freepascal.org/lists/fpc-devel/2010-July/021146.html (at
the bottom)
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Faster InitObject
23.02.2012 11:47, Amir пишет:
Hi,
I have a code, developed in object pascal, with many classes. The
project is working fine.
Today, I used callgrind (valgrind --tool=calgrind) to see which
function consumes the most execution time and I noticed that the most of
time in my project is consumed by fillchar function.
Incl. Self. Called Function
29.78 29.72 26M SYSTEM_FILLCHAR$formal$INT64$BYTE
19.07 19.07 123M SYSTEM_MOVE$formal$formal$INT64
3.63 3.63 70M SYSTEM_SYSGETMEM_FIXED$QWORD$$POINTER
The main caller of FillChar function is
system_TObject_$__NewInstance$$TObject which called Fillchar 26 Million
times.
NewInstance method in TObject calls InitInstance which is an inline
function and defined as follows:
class function TObject.InitInstance(instance : pointer) :
tobject; {$ifdef SYSTEMINLINE} inline; {$ENDIF}
begin
{ the size is saved at offset 0 }
fillchar(instance^, InstanceSize, 0);
{ insert VMT pointer into the new created memory area }
{ (in class methods self contains the VMT!) }
ppointer(instance)^:=pointer(self);
if PVmt(self)^.vIntfTable @emptyintf then
InitInterfacePointers(self,instance);
InitInstance:=TObject(Instance);
end;
My question is do we need to call fillchar in InitInstance? Or Is there
any way to avoid calling InitInstance?
1) You can override TObject.NewInstance, w|o calling inherited. (Init
instance is called from NewInstance) and do whatever you want
2) You can use objects instead of classes if Delphi class model overhead
is significant for you.
--
AVS
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpdoc (trunk) gives AV's
Hi, Note: I can generate the fpGUI documentation without problems using fpdoc from the v2.6.0 release. Last night I implemented displaying a class hierarchy in the linear documentation. Initially for the IPF output writer only. I developed with FPC 2.6.0 and fpdoc worked perfectly. Today I got to work, pulled the latest FPC 2.7.1 and merging my changes into fpdoc. It compiled fine but gave AV's when run. I then reverted my changes and thought I would first test fpdoc from Trunk as-is (none of my modifications). I still got AV's while trying to build the fpGUI documentation. Then I though, maybe the latest fpdoc in Trunk has broken the IPF writer. So I switched to the TXT output writer. I still get AV's. I then reduced the parameters of fpdoc to only processing a single unit in fpGUI. I still got AV's! :-( Here is what I get when I run it via GDB using the TXT output writer. Using FPC 2.7.1 trunk under 64-bit Linux (Ubuntu 10.04). - [docs (master)]$ gdb /opt/fpc-2.7.1/src/utils/fpdoc/fpdoc GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /opt/git/fpc_argon/utils/fpdoc/fpdoc...done. (gdb) set args --format=txt --package=fpgui --input='-Fucorelib /home/graemeg/programming/fpgui/src/corelib/fpg_base.pas' --descr=xml/corelib/fpg_base.xml --output=test.txt (gdb) run Starting program: /opt/git/fpc_argon/utils/fpdoc/fpdoc --format=txt --package=fpgui --input='-Fucorelib /home/graemeg/programming/fpgui/src/corelib/fpg_base.pas' --descr=xml/corelib/fpg_base.xml --output=test.txt FPDoc - Free Pascal Documentation Tool Version 2.7.1 [2012/02/23] (c) 2000 - 2003 Areca Systems GmbH / Sebastian Guenther, s...@freepascal.org Program received signal SIGSEGV, Segmentation fault. 0x0047541a in WRITETYPES (this=0x77f6e040, ASECTION=0x77fc76c0) at dwlinear.pp:896 896 ConvertNotes(TypeDecl,DocNode.Notes); (gdb) bt #0 0x0047541a in WRITETYPES (this=0x77f6e040, ASECTION=0x77fc76c0) at dwlinear.pp:896 #1 0x00474317 in WRITEVARSCONSTSTYPES (this=0x77f6e040, ASECTION=0x77fc76c0) at dwlinear.pp:662 #2 0x004741f7 in PROCESSSECTION (this=0x77f6e040, ASECTION=0x77fc76c0) at dwlinear.pp:647 #3 0x00474079 in WRITEDOC (this=0x77f6e040) at dwlinear.pp:614 #4 0x004a241c in CREATEOUTPUT (this=0x77fc6040, APACKAGE=0x77fe62e0, ENGINE=0x77fc60e0) at mkfpdoc.pp:175 #5 0x004a2ae3 in CREATEDOCUMENTATION (this=0x77fc6040, APACKAGE=0x77fe62e0, PARSEONLY=false) at mkfpdoc.pp:228 #6 0x00402396 in DORUN (this=0x77fce040) at fpdoc.pp:359 #7 0x00465d00 in CUSTAPP$_$TCUSTOMAPPLICATION_$__$$_RUN () #8 0x00402618 in main () at fpdoc.pp:375 (gdb) - I get the exact same when I use the IPF writer. I don't use the new Notes feature at all. I then decided to use a much simpler unit, the fpGUI constants unit. Still no luck! I attached both the constants unit and the description file for that unit. Below is the output GDB have me. - [docs (master)]$ gdb /opt/fpc-2.7.1/src/utils/fpdoc/fpdoc GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /opt/git/fpc_argon/utils/fpdoc/fpdoc...done. (gdb) break fpc_raiseexception Breakpoint 1 at 0x412ba0 (gdb) set args --format=ipf --package=fpgui --input='-Fucorelib /home/graemeg/programming/fpgui/src/corelib/fpg_constants.pas' --descr=xml/corelib/fpg_constants.xml --output=test.ipf (gdb) run Starting program: /opt/git/fpc_argon/utils/fpdoc/fpdoc --format=ipf --package=fpgui --input='-Fucorelib /home/graemeg/programming/fpgui/src/corelib/fpg_constants.pas' --descr=xml/corelib/fpg_constants.xml --output=test.ipf Breakpoint 1, 0x00412ba0 in fpc_raiseexception () (gdb) bt #0 0x00412ba0 in fpc_raiseexception () #1 0x00444378 in CLASSES$_$TFILESTREAM_$__$$_CREATE$ANSISTRING$WORD$LONGWORD$$TFILESTREAM () #2 0x00444129 in CLASSES$_$TFILESTREAM_$__$$_CREATE$ANSISTRING$WORD$$TFILESTREAM () #3 0x004646c7 in
[fpc-devel] Re: fpdoc (trunk) gives AV's
I fixed the bug in fpdoc. A patch is attached to the following bug report. http://bugs.freepascal.org/view.php?id=21357 -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Faster InitObject
Amir schrieb: Hi, I have a code, developed in object pascal, with many classes. The project is working fine. Today, I used callgrind (valgrind --tool=calgrind) to see which function consumes the most execution time and I noticed that the most of time in my project is consumed by fillchar function. Incl. Self. Called Function 29.78 29.7226MSYSTEM_FILLCHAR$formal$INT64$BYTE 19.07 19.07123M SYSTEM_MOVE$formal$formal$INT64 3.633.6370M SYSTEM_SYSGETMEM_FIXED$QWORD$$POINTER I suspect that the procedure initialization time is added to the first explicit statement. The initialization can include try-except/finally blocks, memory allocation (in constructors) or more. Please create another procedure or method, that uses FillChar not as the first statement, and test again. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: fpdoc (trunk) gives AV's
@Marco Instead or reopening the bug report, I'll reply here. It wasn't needed to check for DocNodes.Notes, because it wasn't used anywhere inside the WriteTypes() method, and ConvertNotes() already did the Assigned() check for the Notes property passed in. So your extra check is redundant, but rather safe than sorry I guess. :) G. On 23 February 2012 14:05, Graeme Geldenhuys graemeg.lists@* wrote: I fixed the bug in fpdoc. A patch is attached to the following bug report. http://bugs.freepascal.org/view.php?id=21357 -- Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
Hi, As you can see here http://bugs.freepascal.org/view.php?id=17303 the developer known to LacaK developed a new connector for MSSQLServer, descendant of TSQLConnection class, and sent the beta code in 2010-08-30. Some developers discussed the new code here: http://lazarus.freepascal.org/index.php/topic,15135.msg80922.html#msg80922 I'm already using this connector in production without problems. To FPC core team: Could you take a look in that component and think about included this code in SVN to new developers use too, please? Thanks, Marcos Douglas PS: this message was posted in lazarus-list and fpc-pascal, but I was wrong because nobody answer me about YES or NOT. So, I think this is the right list, don't? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Faster InitObject
On 02/23/2012 02:59 AM, Hans-Peter Diettrich wrote: Amir schrieb: Hi, I have a code, developed in object pascal, with many classes. The project is working fine. Today, I used callgrind (valgrind --tool=calgrind) to see which function consumes the most execution time and I noticed that the most of time in my project is consumed by fillchar function. Incl. Self. Called Function 29.78 29.72 26M SYSTEM_FILLCHAR$formal$INT64$BYTE 19.07 19.07 123M SYSTEM_MOVE$formal$formal$INT64 3.63 3.63 70M SYSTEM_SYSGETMEM_FIXED$QWORD$$POINTER I suspect that the procedure initialization time is added to the first explicit statement. The initialization can include try-except/finally blocks, memory allocation (in constructors) or more. Please create another procedure or method, that uses FillChar not as the first statement, and test again. I am not sure what you are asking. The callgrind outputs the call tree and other information Amir ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Faster InitObject
On 02/23/2012 01:20 AM, Alexander Shishkin wrote: 1) You can override TObject.NewInstance, w|o calling inherited. (Init instance is called from NewInstance) and do whatever you want What does each of the follwoing lines do? It looks like they are setting the function table for the object. So, I need them in my new NewInstance Implementation, don't I? ppointer(instance)^:=pointer(self); if PVmt(self)^.vIntfTable @emptyintf then InitInterfacePointers(self,instance); InitInstance:=TObject(Instance); Amir ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Faster InitObject
23.02.2012 13:16, Sven Barth пишет: In August 2010 Florian already said that maybe FillChar should be optimized: http://lists.freepascal.org/lists/fpc-devel/2010-July/021146.html (at the bottom) In early 2011 I wrote an assembler implementation of FillChar for x86_64 (cannot be used for FreeBSD due to its toolchain problems), it executes approximately 4 times less instructions than generic version. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Faster InitObject
In our previous episode, Sergei Gorelkin said: In August 2010 Florian already said that maybe FillChar should be optimized: http://lists.freepascal.org/lists/fpc-devel/2010-July/021146.html (at the bottom) In early 2011 I wrote an assembler implementation of FillChar for x86_64 (cannot be used for FreeBSD due to its toolchain problems), it executes approximately 4 times less instructions than generic version. Meanwhile 2.6.1 and 2.7.1 should use internal assembler now. Is there something I can test? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Faster InitObject
On 02/23/2012 11:37 AM, Hans-Peter Diettrich wrote: Amir schrieb: Incl. Self. Called Function 29.78 29.72 26M SYSTEM_FILLCHAR$formal$INT64$BYTE 19.07 19.07 123M SYSTEM_MOVE$formal$formal$INT64 3.63 3.63 70M SYSTEM_SYSGETMEM_FIXED$QWORD$$POINTER I suspect that the procedure initialization time is added to the first explicit statement. The initialization can include try-except/finally blocks, memory allocation (in constructors) or more. Please create another procedure or method, that uses FillChar not as the first statement, and test again. I am not sure what you are asking. The callgrind outputs the call tree and other information It's not the first time that somebody complains about slow FillChar. I simply doubt that it really as slow as reported. In above table I'd expect that SysGetMem should be slower than FillChar. DoDi The performance of FillChar is not my problem, The main issue in my case is that my class has a big array defined inside it. I developed my code such that this array does not need to be initialized with zero initially (I have not assumed anything about the content of this array). But the InitInstance function, initialize the array with zero. I can see a simple solution to resolve my problem. I can change the array, in my class, to a dynamic array or pointer or ... But what if I had, let's say, many variables inside my class? Or a big data structure? Amir ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Faster InitObject
On 2/23/2012 03:29, Sven Barth wrote: Am 23.02.2012 09:27 schrieb Sven Barth pascaldra...@googlemail.com mailto:pascaldra...@googlemail.com: Yes, FillChar is needed, because a class instance is guaranteed to have Bennett initialized with zero before the first constructor is called (this way the fields are basically initialized by 0, Nil or '' depending on the field type). Sometimes I hate my phone's autocompletion: it should have been been instead of Bennett... is there a DYAC (Damn You AutoCorrect) for coders? ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fcl-xml updates
Thanks for updating some units :-) I still feel a need for more updates, to replace e.g. WideString in e.g. xmlread.pp. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Faster InitObject
23.02.2012 22:25, Amir пишет: On 02/23/2012 01:20 AM, Alexander Shishkin wrote: 1) You can override TObject.NewInstance, w|o calling inherited. (Init instance is called from NewInstance) and do whatever you want What does each of the follwoing lines do? It looks like they are setting the function table for the object. So, I need them in my new NewInstance Implementation, don't I? ppointer(instance)^:=pointer(self); required if PVmt(self)^.vIntfTable @emptyintf then InitInterfacePointers(self,instance); required for interfaces support InitInstance:=TObject(Instance); required Amir ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Faster InitObject
On 2/23/2012 18:54, Amir wrote: On 02/23/2012 02:20 PM, Hans-Peter Diettrich wrote: The initialization of every class instance is a major improvement over e.g. C++ classes. I'd say that you should accept it, instead of searching for workarounds, with hard to predict effects in the remaining code. I understand that, but I usually forget about it and initialize all my variables to 0 in constructor ;). yet another way that pascal helps you instead of handing you the gun, pointing it at yer foots and assisting you in pulling the trigger ;) ;) :P :lol: ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
