Describe the bug
While trying to understand why a model was getting slower and slower over time I realized that after running it for one hour, most of the computing time was spent in the every operator. Looking at the code it makes sense as it seem to increment a duration in a loop until it reaches current date, so the farthest away the current date the longer it takes.
Additionally I didn't find any use for that kind of incremental code as the operator is not taking into account the particularities of incrementing one month (which could have a different number of days)
as can be demonstrated by this model:
model every
global {
float step <- 1#day;
reflex t when:every(1#month){
write current_date;
}
reflex y when:every(1#year){
write "year " + current_date;
}
reflex end when:current_date = starting_date + 400#day{
do die;
}
}
experiment a;
which yields this result:
1970-01-01 07:00:00
year 1970-01-01 07:00:00
1970-01-30 07:00:00
1970-02-26 07:00:00
1970-03-04 07:00:00
1970-04-01 07:00:00
1970-05-05 07:00:00
1970-05-31 07:00:00
1970-06-30 07:00:00
1970-07-06 07:00:00
1970-08-06 07:00:00
1970-09-28 07:00:00
1970-10-07 07:00:00
1970-11-27 07:00:00
1970-12-08 07:00:00
year 1971-01-01 07:00:00
1971-01-08 07:00:00
Expected behavior
every shouldn't slow down the model
Describe the bug
While trying to understand why a model was getting slower and slower over time I realized that after running it for one hour, most of the computing time was spent in the
everyoperator. Looking at the code it makes sense as it seem to increment a duration in a loop until it reaches current date, so the farthest away the current date the longer it takes.Additionally I didn't find any use for that kind of incremental code as the operator is not taking into account the particularities of incrementing one month (which could have a different number of days)
as can be demonstrated by this model:
which yields this result:
Expected behavior
everyshouldn't slow down the model