gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Parse error in compile_ise.ecf (line 2, column 281): Config file format version missmatch.

[Colin A. <col...@go...>]

No. I'll try it tonight.

On 15/04/2008, Eric Bezault <er...@go...> wrote:
> Colin Adams wrote:
>
> > I get this error even after re-running the bootstrap (ISE 5.7).
> >
>
>  I found that in the file Release_notes.txt:
>
>  ~~~~~~~~~~~~~~~~~~~~~~
>  ISE 5.7 (ISE Eiffel)
>
>         * The ECF files for ISE Eiffel provided in this package are not
>           supported by ISE 5.7. In order to get Ace files instead, you
>           will need to set the environment variable $ISE_5_7, and then
>           run the following commands:
>
>             set ISE_5_7=true
>             cd %GOBO%
>             geant clobber
>             geant install
>  ~~~~~~~~~~~~~~~~~~~~~~
>
>  Did you try that?
>
>  --
>  Eric Bezault
>  mailto:er...@go...
>  http://www.gobosoft.com
>

Re: [gobo-eiffel-develop] some123/fake432/path567

[Emmanuel S. [ES] <ma...@ei...>]

No this is correct. Eric is using a trick of the C compiler that will not
complain for an invalid include file specification. As this is translated
as:

... -Isome123/fake432/path567 -O0 ...

Manu 

> -----Original Message-----
> From: gob...@li... 
> [mailto:gob...@li...] On 
> Behalf Of Berend de Boer
> Sent: Tuesday, April 15, 2008 10:06 PM
> To: Gobo Developers Mailing List
> Subject: [gobo-eiffel-develop] some123/fake432/path567
> 
> Hi All,
> 
> If you use c_compiler_options in .xace you get code like this;
> 
>   <external_include location="some123/fake432/path567 -O0"/>
> 
> I suppose this is a mistake in ET_XACE_ACE_GENERATOR?
> 
> --
> Cheers,
> 
> Berend de Boer
> 

[gobo-eiffel-develop] some123/fake432/path567

[Berend de B. <be...@po...>]

Hi All,

If you use c_compiler_options in .xace you get code like this;

  <external_include location="some123/fake432/path567 -O0"/>

I suppose this is a mistake in ET_XACE_ACE_GENERATOR?

-- 
Cheers,

Berend de Boer

Re: [gobo-eiffel-develop] Parse error in compile_ise.ecf (line 2, column 281): Config file format version missmatch.

[Eric B. <er...@go...>]

Colin Adams wrote:
> I get this error even after re-running the bootstrap (ISE 5.7).

I found that in the file Release_notes.txt:

~~~~~~~~~~~~~~~~~~~~~~
ISE 5.7 (ISE Eiffel)

	* The ECF files for ISE Eiffel provided in this package are not
	  supported by ISE 5.7. In order to get Ace files instead, you
	  will need to set the environment variable $ISE_5_7, and then
	  run the following commands:

	    set ISE_5_7=true
	    cd %GOBO%
	    geant clobber
	    geant install
~~~~~~~~~~~~~~~~~~~~~~

Did you try that?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] Parse error in compile_ise.ecf (line 2, column 281): Config file format version missmatch.

[Colin A. <col...@go...>]

I get this error even after re-running the bootstrap (ISE 5.7).

[gobo-eiffel-develop] Need to accomodate STRING_32 in Gobo

[Colin A. <col...@go...>]

I have just implemented the following routine:
	
draw_text (x, y: INTEGER; a_text: STRING_GENERAL) is
			-- Draw `a_text' with left of baseline at (`x', `y') using `font'.
		local
			l_element: XM_ELEMENT
			l_attribute: XM_ATTRIBUTE
			l_text: XM_CHARACTER_DATA
			l_bytes: STRING
			l_utf8: UC_UTF8_STRING
		do
			create l_element.make_last (document.root_element, Svg_text, Svg_namespace)
			create l_element.make_last (Svg_x_attribute, Svg_namespace, x.out, l_element)
			create l_element.make_last (Svg_y_attribute, Svg_namespace,
(-y).out, l_element)
			add_font_attributes (l_element)
			if a_text.is_string_8 then
				create l_text.make_last (l_element, a_text.as_string_8)
			else
				create l_bytes.make (a_text.count * 4)
				from
					i := 1
				until
					i > a_text.count
				loop
					utf8.append_code_to_utf8 (l_bytes, a_text.item_code (i))
					i := i + 1
				end
				create l_utf8.make_from_utf8 (l_bytes)
				create l_text.make_last (l_element, l_utf8)
			end
		end

We need a make_from_utf32 (or some such routine) in UC_STRING (or
alternatively let XM_CHARACTER_DATA accept a STRING_GENEAL, or
prefereably both).

Re: [gobo-eiffel-develop] Errors caught by gelint in XM_XPATH classes

[Colin A. <col...@go...>]

I will deal with this next weekend, as I only have a laptop this weekend.
Also Unicode 5.1 has been released a week ago, so I will prepare an
update for that too.

On 10/04/2008, Eric Bezault <er...@go...> wrote:
> Gelint reports the following errors:
>
>  [VUAR-2] class XM_XPATH_ARRAY_LIST_ITERATOR (33,25): the 1-th actual
>  argument (of type 'NONE') does not conform to the corresponding formal
>  argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
>  ----
>  [VUAR-2] class XM_XPATH_ARRAY_LIST_ITERATOR (46,25): the 1-th actual
>  argument (of type 'NONE') does not conform to the corresponding formal
>  argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
>  ----
>  [VUAR-2] class XM_XPATH_ARRAY_LIST_ITERATOR (205,21): the 1-th actual
>  argument (of type 'NONE') does not conform to the corresponding formal
>  argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
>  ----
>  [VUAR-2] class XM_XPATH_REVERSE_ARRAY_LIST_ITERATOR (33,25): the 1-th
>  actual argument (of type 'NONE') does not conform to the corresponding
>  formal argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
>  ----
>  [VUAR-2] class XM_XPATH_REVERSE_ARRAY_LIST_ITERATOR (46,25): the 1-th
>  actual argument (of type 'NONE') does not conform to the corresponding
>  formal argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
>  ----
>  [VUAR-2] class XM_XPATH_REVERSE_ARRAY_LIST_ITERATOR (174,21): the 1-th
>  actual argument (of type 'NONE') does not conform to the corresponding
>  formal argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
>  ----
>
>  One way to solve this problem is to use inline agents ;-)))
>  Anyway, the assertions are obviously wrong, it should be:
>
>    no_void_item: not a_list.has (Void)
>                  ^^^
>  Probably not caught earlier because of the bug in gexace.
>
>  OK, I can feel the fact that you don't want to use inline
>  agents. So, there are several other solutions.
>
>  1) Add a routine `has_default' in class DS_SEARCHABLE.
>
>  2) Add a routine `default_item: G' in your class and
>     call: not a_list.has (default_item). But this will
>     not be practical for assertions in creation routines.
>
>  3) Use KL_ANY_ROUTINES.same_objects:
>      not a_list.there_exists (agent ANY_.same_objects (?, Void))
>
>  Solution 3 is the one which will work without any additional
>  code.
>
>  PS: I would tend to avoid declaring the generic parameter
>  as 'reference G' because it is not part of ECMA Eiffel is
>  I remember correctly.
>
>  --
>  Eric Bezault
>  mailto:er...@go...
>  http://www.gobosoft.com
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  gobo-eiffel-develop mailing list
>  gob...@li...
>  https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>

[gobo-eiffel-develop] Errors caught by gelint in XM_XPATH classes

[Eric B. <er...@go...>]

Gelint reports the following errors:

[VUAR-2] class XM_XPATH_ARRAY_LIST_ITERATOR (33,25): the 1-th actual 
argument (of type 'NONE') does not conform to the corresponding formal 
argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
----
[VUAR-2] class XM_XPATH_ARRAY_LIST_ITERATOR (46,25): the 1-th actual 
argument (of type 'NONE') does not conform to the corresponding formal 
argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
----
[VUAR-2] class XM_XPATH_ARRAY_LIST_ITERATOR (205,21): the 1-th actual 
argument (of type 'NONE') does not conform to the corresponding formal 
argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
----
[VUAR-2] class XM_XPATH_REVERSE_ARRAY_LIST_ITERATOR (33,25): the 1-th 
actual argument (of type 'NONE') does not conform to the corresponding 
formal argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
----
[VUAR-2] class XM_XPATH_REVERSE_ARRAY_LIST_ITERATOR (46,25): the 1-th 
actual argument (of type 'NONE') does not conform to the corresponding 
formal argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
----
[VUAR-2] class XM_XPATH_REVERSE_ARRAY_LIST_ITERATOR (174,21): the 1-th 
actual argument (of type 'NONE') does not conform to the corresponding 
formal argument (of type 'G') of feature `has' in class DS_ARRAYED_LIST.
----

One way to solve this problem is to use inline agents ;-)))
Anyway, the assertions are obviously wrong, it should be:

   no_void_item: not a_list.has (Void)
                 ^^^
Probably not caught earlier because of the bug in gexace.

OK, I can feel the fact that you don't want to use inline
agents. So, there are several other solutions.

1) Add a routine `has_default' in class DS_SEARCHABLE.

2) Add a routine `default_item: G' in your class and
    call: not a_list.has (default_item). But this will
    not be practical for assertions in creation routines.

3) Use KL_ANY_ROUTINES.same_objects:
     not a_list.there_exists (agent ANY_.same_objects (?, Void))

Solution 3 is the one which will work without any additional
code.

PS: I would tend to avoid declaring the generic parameter
as 'reference G' because it is not part of ECMA Eiffel is
I remember correctly.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] C compiler warnings when bootstrapping

[Eric B. <er...@go...>]

Berend de Boer wrote:
> Hi All,
> 
> Upgraded to the latest version last night and got this:
> 
> # ./bootstrap.sh gcc ge
> geant4.c: In function 'T55f41':
> geant4.c:6703: warning: passing argument 1 of 'GE_check_void' discards qualifiers from pointer target type
> geant4.c:6710: warning: passing argument 2 of 'T55f60' discards qualifiers from pointer target type
> geant4.c:6714: warning: passing argument 2 of 'T17f17' discards qualifiers from pointer target type
> geant4.c:6714: warning: passing argument 2 of 'T204f13' discards qualifiers from pointer target type
> geant4.c:6719: warning: assignment discards qualifiers from pointer target type
> geant4.c:6721: warning: assignment discards qualifiers from pointer target type
> geant4.c:6743: warning: passing argument 2 of 'T76f1' discards qualifiers from pointer target type
> geant4.c:6743: warning: passing argument 3 of 'T76f1' discards qualifiers from pointer target type
> ...
> 
> It builds the executables though (they are only warnings), but in case
> someone is interested. I'm using gcc 4.1.1.

The problem seems to be as follows. I have a local variable which
needs to be declared as volatile (because of the use of setjmp/longjmp):

   volatile T0* l1 = 0;

And then I call:

   f(l1);

where `f' is declared as follows:

   void f(T0* a1);

with no volatile qualifier. I think that this is what gcc is
complaining about. Anyone knows how to make gcc happy?
Should I declare my local variable as:

   T0 volatile *l1 = 0;

instead of:

   volatile T0* l1 = 0;

Or should I explicitly cast it as follows:

   f((T0*)l1);

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] C compiler warnings when bootstrapping

[Berend de B. <be...@po...>]

Hi All,

Upgraded to the latest version last night and got this:

# ./bootstrap.sh gcc ge
geant4.c: In function 'T55f41':
geant4.c:6703: warning: passing argument 1 of 'GE_check_void' discards qualifiers from pointer target type
geant4.c:6710: warning: passing argument 2 of 'T55f60' discards qualifiers from pointer target type
geant4.c:6714: warning: passing argument 2 of 'T17f17' discards qualifiers from pointer target type
geant4.c:6714: warning: passing argument 2 of 'T204f13' discards qualifiers from pointer target type
geant4.c:6719: warning: assignment discards qualifiers from pointer target type
geant4.c:6721: warning: assignment discards qualifiers from pointer target type
geant4.c:6743: warning: passing argument 2 of 'T76f1' discards qualifiers from pointer target type
geant4.c:6743: warning: passing argument 3 of 'T76f1' discards qualifiers from pointer target type
...

It builds the executables though (they are only warnings), but in case
someone is interested. I'm using gcc 4.1.1.

-- 
Cheers,

Berend de Boer

Re: [gobo-eiffel-develop] Assertion checking with ISE 6.1

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
> Caution!
> 
> It appears geant test/compile_debug_ise does NOT result in
> any assertion checking.

There was a bug in gexace. It's now fixed in svn#6342.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] Assertion checking with ISE 6.1

[Colin P. A. <co...@co...>]

Caution!

It appears geant test/compile_debug_ise does NOT result in
any assertion checking.

I'm cleaning my code now as a result of this discovery.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Memory allocation overhead

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>     EB> I just saw that in your last check-in you used MEMORY.free.
>     EB> This is a bad idea in my opinion.
> 
> Why? I was only using it in places where I could guarantee that the
> object wouldn't be used again (not a frequent case).

It's a bad idea for two reasons. If GC have been invented,
it's because we cannot trust humans, including you. You
can guarantee that the object would not be used again
today. But what about in two years from now, after several
iterations of refactoring? And I usually don't trust
features/constructs that nobody else (except Lothar) used
despite the fact that it has been available for more
than a decade, and even more when it is related to a
so complex thing as a GC. You can use it at your own
risk in gestalt or other developments, but if possible
it would be nice if we could refrain from using it in
the Gobo package.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Memory allocation overhead

[Eric B. <er...@go...>]

Lothar Scholz wrote:
> EB> I just saw that in your last check-in you used MEMORY.free.
> EB> This is a bad idea in my opinion. And it won't help anyway
> EB> when using gec+boehm (it's currently implemented as a no-op).
> 
> Which GC version are you using? GC_free is implemented in "malloc.c"
> and it works fine. I used it starting with 6.7 upto the latest
> 7.1.beta3-snapshot it was never a no-op.

I didn't say that GC_free was a no-op. MEMORY.free is.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Memory allocation overhead

[Colin P. A. <co...@co...>]

>>>>> "Lothar" == Lothar Scholz <ll...@we...> writes:


    EB> I just saw that in your last check-in you used MEMORY.free.
    EB> This is a bad idea in my opinion.

Why? I was only using it in places where I could guarantee that the
object wouldn't be used again (not a frequent case).
It can cut down the amount of work needed by the next mark cycle.

    EB> And it won't help anyway
    EB> when using gec+boehm (it's currently implemented as a no-op).

    Lothar> Which GC version are you using? GC_free is implemented in
    Lothar> "malloc.c" and it works fine. I used it starting with 6.7
    Lothar> upto the latest 7.1.beta3-snapshot it was never a no-op.

    Lothar> I'm using it a lot to free large buffers and it helps to
    Lothar> keep memory footprint small. Waiting for a 500 KByte
    Lothar> memory chunk to get freed by a conservative GC is just
    Lothar> extremely risky.

    Lothar> Remember if you using double and real values you might
    Lothar> have a lot of false positives.

But Gobo code has to work with ISE as well as GEC. And Manu warned
that it might fail with ISE, as the C code might continue to hold a
reference to the object. That's why I removed the calls to free.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Memory allocation overhead

[Lothar S. <ll...@we...>]

Hello Eric,

Friday, April 4, 2008, 11:55:10 PM, you wrote:

EB> Eric Bezault wrote:
>> Colin Paul Adams wrote:
>>> Do you use free at all? Obviously that won't reduce the number of
>>> allocations, but it will reduce the number of objects the GC has to
>>> deal with. Does it give any advantage over assigning Void to the
>>> reference?
>> 
>> I don't use free.

EB> I just saw that in your last check-in you used MEMORY.free.
EB> This is a bad idea in my opinion. And it won't help anyway
EB> when using gec+boehm (it's currently implemented as a no-op).

Which GC version are you using? GC_free is implemented in "malloc.c"
and it works fine. I used it starting with 6.7 upto the latest
7.1.beta3-snapshot it was never a no-op.

I'm using it a lot to free large buffers and it helps to keep
memory footprint small. Waiting for a 500 KByte memory chunk to
get freed by a conservative GC is just extremely risky.

Remember if you using double and real values you might have a lot
of false positives.


-- 
Best regards,
 Lothar                            mailto:ll...@we...

Re: [gobo-eiffel-develop] Iterators for DS_TABLE?

[Eric B. <er...@go...>]

Eric Bezault wrote:
> Colin Adams wrote:
 >> Eric Bezault wrote:
>>>  Well, in fact to iterate only on keys I guess we can do
>>>  `my_table.keys.do_all'... So, we might need only two kinds of
>>>  iterators after all. What about `do_all' and `do_all_with_key',
>>>  the latter being similar to `do_all_with_index'?
>> Yes, that sounds the best compromise.

Done. I did `do_all_with_key' and `do_if_with_key' because
we already had similar routines for `do_all_with_index' and
`do_if_with_index'. Since we didn't have `for_all_with_index'
and `there_exists_with_index', I didn't provide the `..._with_key'
counterpart either.

>>>  Note that DS_TABLE is not linear. Only DS_SPARSE_TABLE is.
>>>  I don't remember why DS_TABLE is not linear, but I'm not
>>>  currently in a mood to change that to make it linear.
>> There is nothing linear about for_all_with_keys and there_exists_with_keys.
>> Do_all_with_index/do_if_with_index imply a linear ordering, so we
>> won't want them in DS_TABLE.
> 
> I should have said that DS_TABLE is not a descendant of
> DS_TRAVERSABLE (rather than a descendant of DS_LINEAR).
> 
> I would say that `do_all_with_index' belongs to DS_INDEXABLE.
> It has been added to DS_LINEAR for convenience (perhaps
> DS_LINEAR should have been a descendant of DS_INDEXABLE).
> 
>> I see no implied linearity with
>> do_all_with_keys, do_if_with_keys (or for that matter do_all and
>> do_if, just from the names). It all depends upon what the header
>> comment says. So for do_all_with_keys we can just word the header
>> comment to state that no particular order may be relied upon. Likewise
>> for do_if_with_keys. 
> 
> If we follow the same reasoning, that `do_all', `there_exists',
> etc. should be moved to DS_CONTAINER.

I moved `do_all', `do_if', `there_exists' and `for_all' to
class DS_CONTAINER. And the `..._with_key' routines have
been introduced in class DS_TABLE.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Memory allocation overhead

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    >> Are other features of MEMORY (such as allocate_fast and
    >> set_memory_threshold) implemented?

    Eric> Not yet in gec. And I haven't studied yet whether the Boehm
    Eric> GC would provide such functionality.

OK.

But in any case, I am fairly confident that I know what the basic
problem I have is. Fixing it is another matter.

XSLT is largely concerned with manipulating strings. So I think the
lack of read-only strings, enabling substring to avoid copying the
string contents, is likely a very major factor.

I have some evidence in support of this.

1) The runtime of my program is non-linear wrt the size of the input
data set.
2) If I use the tiny tree implementation for the input data set, the
runtime increases by more than 4 times.

The tiny tree implementation is an application of
the flyweight pattern, designed to reduce the number of objects
created. I copied the idea from Saxon (the contents of all text and
comment nodes is held as a single STRING object within the document,
and access to it is by substring, avoiding creating text and comment
node objects for this purpose), but I overlooked that substring copies
the data in Eiffel.

Accordingly, I think I shall abandon my efforts for now, and pursue
Manu's suggestion in FreeELKS for an aliased substring feature (I
think full copy-on-write semantics will need to be available for
STRINGs). 
I don't doubt that there are opportunities to improve my use of
STRINGs in the code (a review would help), but I think this needs
tackling first.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Memory allocation overhead

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
> I would expect this to be a no-op. Is it not a call that provides
> typing information only to the compiler, so that at run-time there is
> not need for it?

As I claimed many times in the past, no effort has been
made yet to improve the performance of the generated C
code. IN particular in term of inlining or dynamic
binding.

My priority is to be fully compliant with ECMA and ISE
before tackling performance issues. And from what I can
see, spending time on this issue now will not significantly
improve your figures as long as most of the time is still
spent in the GC.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Memory allocation overhead

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> I just saw that in your last check-in you used MEMORY.free.
>     Eric> This is a bad idea in my opinion. And it won't help anyway
>     Eric> when using gec+boehm (it's currently implemented as a
>     Eric> no-op).
> 
> Are other features of MEMORY (such as allocate_fast and
> set_memory_threshold) implemented?

Not yet in gec. And I haven't studied yet whether the
Boehm GC would provide such functionality.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Memory allocation overhead

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> I would surprise me that the level of inlining currently
    Eric> implemented in gec has anything to do with the time actually
    Eric> spent in the GC that was shown in your profiling results.

That may be the case, but there is some (doubtful) evidence to the
contrary.

Since currently my execution time is approaching 4 times faster than
when I previously profiled, I thought I would profile again to confirm
that GC problems are still predominant (I was fairly sure they were,
as top shows 200-300% CPU utilization still, which can only come from
parallel marking).

The new profile confirms this is the case, but there is the suggestion
that a failure to inline will be significant if the GC overhead could
be largely eliminated (I have named the top three calls - I'm assuming
the comment in the .h file immediately precedes the extern
declaration.):

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name    
 31.55    675.04   675.04                             GC_mark_from
 16.24   1022.55   347.51                             GC_steal_mark_stack
 16.17   1368.49   345.94                             GC_header_cache_miss
  8.08   1541.30   172.81                             GC_mark_local
  1.44   1572.07    30.77                             GC_reclaim_clear
  1.27   1599.21    27.14 530952040     0.00     0.00  T131f10 DS_ARRAYED_LIST [INTEGER_32].item
  1.19   1624.57    25.36                             GC_push_marked
  0.84   1642.47    17.90                             GC_generic_malloc_many
  0.81   1659.80    17.34 128695782     0.00     0.00  T171x16745 XM_XPATH_NODE.as_tree_node
  0.77   1676.37    16.57 262642848     0.00     0.00  T515f29 XM_XPATH_ATTRIBUTE_COLLECTION.is_attribute_index_valid
  0.64   1690.09    13.72                             GC_do_local_mark
  0.58   1702.48    12.39 181451145     0.00     0.00  T17x34
  0.52   1713.50    11.02 181905247     0.00     0.00  T15f4
  0.50   1724.23    10.73                             GC_malloc
  0.50   1734.90    10.67                             GC_block_was_dirty
  0.47   1745.00    10.10                             GC_apply_to_all_blocks
  0.34   1752.22     7.22
  GC_install_header

So we can see that the second highest Eiffel routine is
XM_XPATH_NODE.as_tree_node. Since the definition of this is:

	as_tree_node: XM_XPATH_TREE_NODE is
			-- `Current' seen as a tree node
		do
			Result := Current
		end

I would expect this to be a no-op. Is it not a call that provides
typing information only to the compiler, so that at run-time there is
not need for it?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Memory allocation overhead

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> I just saw that in your last check-in you used MEMORY.free.
    Eric> This is a bad idea in my opinion. And it won't help anyway
    Eric> when using gec+boehm (it's currently implemented as a
    Eric> no-op).

Are other features of MEMORY (such as allocate_fast and
set_memory_threshold) implemented?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Memory allocation overhead

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> I would surprise me that the level of inlining currently
    Eric> implemented in gec has anything to do with the time actually
    Eric> spent in the GC that was shown in your profiling results.

I later checked in the gestalt.h file, and there was no trace of these
routines. So I guess they were optimized away (in one case) and
inlined in the others.
I don't understand how the runtime increase could have occured, but I
have abandoned that approach now.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Memory allocation overhead

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> I just saw that in your last check-in you used MEMORY.free.
I've removed it now.

-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Memory allocation overhead

[Colin P. A. <co...@co...>]

>>>>> "Emmanuel" == Emmanuel Stapf [ES] <ma...@ei...> writes:

    Emmanuel> think there are no references to the object, the
    Emmanuel> generated C code might still have a reference or two. So
    Emmanuel> at the next GC cycle it could basically cause a problem
    Emmanuel> (be a segmentation violation or something else). I'm not
    Emmanuel> sure why it was added in MEMORY at the first place, but
    Emmanuel> I would not use it.

In that case it had better be marked obsolete.
-- 
Colin Adams
Preston Lancashire