>>>>> "Eric" == Eric Bezault <
ericb@...> 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_______________________________________________
gobo-eiffel-develop mailing list
gobo-eiffel-develop@...
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
