Re: Memory allocation overhead

>>>>> "Eric" == Eric Bezault <[email protected]> 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

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Register now and save $200. Hurry, offer ends at 11:59 p.m., 
Monday, April 7! Use priority code J8TLD2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone