Paul Ishenin schrieb:
For some reason the visibility is completely ignored here. I can add a
class helper to the strict private or even move it to another unit - it
is always visible.
IMO class helper methods always should become visible as part of the
class, regardless of where they are
On 30.01.2011 09:03, Hans-Peter Diettrich wrote:
Paul Ishenin schrieb:
For some reason the visibility is completely ignored here. I can add a
class helper to the strict private or even move it to another unit -
it is always visible.
IMO class helper methods always should become visible as
On 30.01.2011 04:30, Paul Ishenin wrote:
30.01.2011 5:22, Sven Barth wrote:
Ok, I have now implemented a set of flags in TSymtable of which one is
set when the (global-,static-)symtable contains a class helper (I
haven't refactored b_needs_init_final yet).
Here are the new results with the
30.01.2011 15:45, Sven Barth wrote:
Imo it works much better now.
Only one minute slower in the complete run instead of four. I let you
guys decide whether this is good enough ^^
2m22.980s -
2m15.362s =
0m7.xxxs - were is a minute?
How often is the compiler compiled completly during a make
On 30.01.2011 09:55, Paul Ishenin wrote:
30.01.2011 15:45, Sven Barth wrote:
Imo it works much better now.
Only one minute slower in the complete run instead of four. I let you
guys decide whether this is good enough ^^
2m22.980s -
2m15.362s =
0m7.xxxs - were is a minute?
That was two runs
On 29.01.2011 23:22, Sven Barth wrote:
Ok, I have now implemented a set of flags in TSymtable of which one is
set when the (global-,static-)symtable contains a class helper (I
haven't refactored b_needs_init_final yet).
I have commited the changes now as well (I was too tired yesterday), so
30.01.2011 16:22, Sven Barth wrote:
I have commited the changes now as well (I was too tired yesterday),
so please fell free to critize them (especially the ones in ppudump)
as I need to build on on these changes regarding b_needs_init_final
(or should this wait until everything is merged back
30.01.2011 16:22, Sven Barth wrote:
I have commited the changes now as well (I was too tired yesterday),
so please fell free to critize them (especially the ones in ppudump).
Why do you need ibsymtableoptions ?
Best regards,
Paul Ishenin
___
On 30.01.2011 11:30, Paul Ishenin wrote:
30.01.2011 16:22, Sven Barth wrote:
I have commited the changes now as well (I was too tired yesterday),
so please fell free to critize them (especially the ones in ppudump).
Why do you need ibsymtableoptions ?
tstoredsymtable stores only definitions
On 30 Jan 2011, at 09:45, Sven Barth wrote:
Only one minute slower in the complete run instead of four. I let you guys
decide whether this is good enough ^^
It's still a lot of overhead.
An alternative solution could be to add a hashtable (tfphaslist) to tmodule
whose entries are hashed on
Am 29.01.2011 23:22, schrieb Sven Barth:
Here are the new results with the search for class helpers enabled (only
two runs this time):
Run 1:
real2m22.980s
user0m47.140s
sys0m4.333s
Run 2:
real2m15.362s
user0m47.274s
sys0m4.140s
With which times are those
On 30.01.2011 12:13, Florian Klämpfl wrote:
Am 30.01.2011 09:45, schrieb Sven Barth:
On 30.01.2011 04:30, Paul Ishenin wrote:
30.01.2011 5:22, Sven Barth wrote:
Ok, I have now implemented a set of flags in TSymtable of which one is
set when the (global-,static-)symtable contains a class
On 30.01.2011 12:06, Jonas Maebe wrote:
On 30 Jan 2011, at 09:45, Sven Barth wrote:
Only one minute slower in the complete run instead of four. I let you guys
decide whether this is good enough ^^
It's still a lot of overhead.
Yes and that's why I'm thankful for every suggestion I can
30.01.2011 15:45, Sven Barth wrote:
Only one minute slower in the complete run instead of four. I let you
guys decide whether this is good enough ^^
How often is the compiler compiled completly during a make cycle?
I still see an ability to optimize your implementation.
procedure
On Sunday, 30. January 2011 12.13:21 Florian Klämpfl wrote:
Actually I think anything about a ten percent slower compiler will
people make cry ... And as far as I understand, for projects with a lot
of units it will be even worse, right?
I cry if FPC doesn't compile at least ten percent
Am 30.01.2011 12:37, schrieb Martin Schreiber:
On Sunday, 30. January 2011 12.13:21 Florian Klämpfl wrote:
Actually I think anything about a ten percent slower compiler will
people make cry ... And as far as I understand, for projects with a lot
of units it will be even worse, right?
I cry
On 30 Jan 2011, at 12:37, Martin Schreiber wrote:
I cry if FPC doesn't compile at least ten percent *faster* than the previous
release...
At least on Mac OS X/i386, we are pretty close to that currently as far as
compiling the compiler with itself is concerned:
* Compiling it with 2.4.2:
On 30.01.2011 12:36, Paul Ishenin wrote:
30.01.2011 15:45, Sven Barth wrote:
Only one minute slower in the complete run instead of four. I let you
guys decide whether this is good enough ^^
How often is the compiler compiled completly during a make cycle?
I still see an ability to optimize
In our previous episode, Sven Barth said:
Actually I think anything about a ten percent slower compiler will
people make cry ... And as far as I understand, for projects with a lot
of units it will be even worse, right?
I cry if FPC doesn't compile at least ten percent *faster* than
current trunk doesn't build. fails on pxlib
- make clean
- make all
- make zipinstall
Platform i-386-win32
OS XP sp3
Bootstrap 2.4.2
---
make[3]: Entering directory `C:/FPC/2.5.1/packages/pxlib'
make all LINKSMART=1 CREATESMART=1
make[4]: Entering directory `C:/FPC/2.5.1/packages/pxlib'
30.01.2011 19:41, Sven Barth wrote:
procedure update_unit_symtable_options;
var
st: tsymtable;
begin
st:=owner;
while not(st.symtabletype in [globalsymtable,staticsymtable]) do
st:=st.defowner.owner;
if objecttype in [odt_classhelper,odt_objccategory] then
Sven Barth schrieb:
Sorry, I don't understand what you want to tell here.
Sorry2, I'll retry.
I personally expect a class helper that is defined inside a private
section of a class not to be available in another unit like I can't
access a field or another type defined in there as well.
Jonas Maebe schrieb:
An alternative solution could be to add a hashtable (tfphaslist) to
tmodule whose entries are hashed on the qualified class names
(unit$classname, since different units can contain classes with the
same name). The value of such an entry would a tfpobjectlist of class
On 31-1-2011 2:06, Hans-Peter Diettrich wrote:
Jonas Maebe schrieb:
Is the hashtable *really* rebuilt with every push and pop of another
symtable? It would be much easier to have a hashtable per symtable,
that deserves no further modifications. When all hashtables use the
same hash
Am Montag, 31. Januar 2011 00:57 schrieb Paul Ishenin:
31.01.2011 0:26, Sven Barth wrote:
Timings without that change:
Run 1:
real1m3.461s
user0m45.957s
sys0m4.590s
Timings with that change:
Run 1:
real1m8.919s
user0m46.597s
sys0m4.166s
But
25 matches
Mail list logo
