Related articles |
---|
Data flow analysis scrufffymydog@juno.com (2004-06-25) |
Re: Data flow analysis mdanish@andrew.cmu.edu (Matthew Danish) (2004-06-28) |
Re: Data flow analysis cfc@shell01.TheWorld.com (Chris F Clark) (2004-06-28) |
Re: Data flow analysis vbdis@aol.com (2004-06-28) |
Data Flow Analysis ehyde@top.cis.syr.edu (1991-06-11) |
Data flow analysis lee@cadenza.rutgers.edu (1992-04-14) |
Data Flow Analysis gremlin@cs.huji.ac.il (Ofer Ben-Ami) (1997-01-07) |
From: | Chris F Clark <cfc@shell01.TheWorld.com> |
Newsgroups: | comp.compilers |
Date: | 28 Jun 2004 20:00:12 -0400 |
Organization: | The World Public Access UNIX, Brookline, MA |
References: | 04-06-093 |
Keywords: | analysis |
Posted-Date: | 28 Jun 2004 20:00:12 EDT |
Yes, things like you have described have been attempted. I'm not
aware of your specific example, but "Third Degree" a heap profiling
tool that I worked on as a consultant for Digital (became Compaq
became HPQ) did something very similar to what you are describing.
The essential problem is that you are maintinaing a database with one
entry per pixel (or group of pixels, as most code doesn't actually
write pixels, but writes icons, windows, scroll-bars, and other higher
level things). Now, each time some code in the application changes
those pixels, you need to update your database. However, some places
where the application looks like it might be changing pixels, it may
not be changing ownership. You can resolve that question using
dataflow analysis (unfortunately often abbreviated DFA), which will
allow you to "prove" that some section of code while modifying the
screen, is only modfying the same parts of the screen it has modified
before. Then, you know that you can move the computation of that
ownership (out of a loop) into a lower cost part of the code.
Your second more subtle question (about passing ownership through
different layers of the code) can be answered through a dataflow
analysis technique called "value propagation".
All that said, you may find as much information can be learned from
the graphic domain, as you are probably as likely to be interested in
bounding-boxes and overlaps as you are in code structure. as,
performance will probably be an issue. Once could keep a per pixel
representation of every pixel on the screen and update it at every
"instant", but the result would be an utter pig.
Hope this helps,
-Chris
*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------
Return to the
comp.compilers page.
Search the
comp.compilers archives again.