Closed Haiyang-Sun closed 5 years ago
Nice, that's an easy improvement, I had a similar (basically the same) patch in a branch for a while, but never got around to merging it, sorry. (I was planning to collect some stats around it, but that never happened.)
For reference, here's my version (2 fewer calls to the maps, probably not measurable):
diff --git a/src/ch.usi.inf.nodeprof/src/ch/usi/inf/nodeprof/utils/SourceMapping.java b/src/ch.usi.inf.nodeprof/src/ch/usi/inf/nodeprof/utils/SourceMapping.java
index 9057c48..0b15ec2 100644
--- a/src/ch.usi.inf.nodeprof/src/ch/usi/inf/nodeprof/utils/SourceMapping.java
+++ b/src/ch.usi.inf.nodeprof/src/ch/usi/inf/nodeprof/utils/SourceMapping.java
@@ -55,9 +55,7 @@ public abstract class SourceMapping {
}
int newIId = ++iidGen;
assert (newIId < Integer.MAX_VALUE);
- StringBuilder b = makeLocationString(sourceSection);
- iidMap.put(newIId, b.toString());
sourceSet.put(sourceSection, newIId);
idToSource.put(newIId, sourceSection);
return newIId;
@@ -65,7 +63,16 @@ public abstract class SourceMapping {
@TruffleBoundary
public static String getLocationForIID(int iid) {
- return iidMap.get(iid);
+ String loc = iidMap.get(iid);
+ if (loc == null) {
+ SourceSection sourceSection = idToSource.get(iid);
+ if (sourceSection != null) {
+ StringBuilder b = makeLocationString(sourceSection);
+ loc = b.toString();
+ iidMap.put(iid, loc);
+ }
+ }
+ return loc;
}
@TruffleBoundary
Currently, the location string for an iid is created when allocating the iid, however, this could lead to unnecessary memory use if such iid is never used. Cache it lazily on demand would solve this issue.