Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006217OCamlOCaml backend (code generation)public2013-10-30 15:082014-07-16 13:49
Reporterppedrot 
Assigned To 
PrioritynormalSeveritytweakReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version4.01.0 
Target VersionFixed in Version 
Summary0006217: Compilation of record functional modification is costly
DescriptionCurrently, compilation of the { r with ... } expression seems to have a length threshold that triggers a change in the way it is compiled. For instance,

type t = {
  t1 : int option;
  t2 : int option;
  t3 : int option;
  t4 : int option;
  t5 : int option;
}

let set1 x t = {
  t with t1 = Some x;
}

produces a direct allocation on the minor heap, together with a bunch of assembly moves that copy the record fieldwise. Problem is, adding a [t6 : int option] field changes this to an [Obj.dup] followed by a [caml_modify].

I don't know if this has been decided with respect to some benchmarks, but [caml_modify] is really costly, and for the record (no pun intended), this overhead was indeed observable in Coq. Maybe this threshold should be incremented?
Tagsjunior_job
Attached Files

- Relationships

-  Notes
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2013-10-30 15:08 ppedrot New Issue
2014-06-19 17:42 gasche Tag Attached: junior_job
2014-07-16 13:49 doligez Status new => acknowledged


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker