Speed up Custom Column

I am trying to use a custom column to make a folder format in which files are ordered by their parent folder's modified time, by location and by name, in that order.

For 1K files the values of the custom column are calculated quickly. For 8K files it takes quite a while. Many files have the same parent, but I don't know how to leverage that to set multiple values at once.

The custom column value is mainly produced by:

if (colName == 'Parent\'s Modified Date') {
		parentPath = DOpus.FSUtil.NewPath(ColumnData.item);
		parentPath.Parent();
		parentItem = DOpus.FSUtil.GetItem(parentPath);
		modifiedDate = parentItem.modify_utc;
		ColumnData.value = modifiedDate;
}

Any suggestion on how to speed up that column?

The main aim is to have the files ordered by time (newest to oldest) at the folder level and by name at the file level. I considered using groups and flat view, but using a custom column has been the closest I got. Suggestion of alternatives are welcomed too.

First thing to do is confirm what you think is slowing it down really is, since it can come from unexpected places sometimes.

If you comment out the last three lines of the function, does it speed up?

If you then add them back, top to bottom, which line(s) are causing the slowdown?

1 Like

The script is instantiated once each time the column is refreshed. If reading the parent from the file system is what takes time you could create an array global to the script. Look there for the data (keyed off full path) before trying to load it from the file system. I would expect this to be faster if many files share the same parent.

1 Like

Only ColumnData.value = ColumnData.item.modify_utc; instead of the five lines above is a bit faster for 8K files, but still not nearly instantly as the native modified column.

Nice idea, probably could work.


I changed my requirements for the folder format to include grouping with another custom column, so some wait time will be inevitable. Because of that, I decided not to pursue an optimization for this column anymore.

I'll mark this as resolved. Thank you.

Maybe it's still worth adding these few lines.
If not then this might still be an example of what wowbagger suggested:

//storing already know dates for folders here
//this var needs to be outside of the column function in the global scope of the script
//the global scope of the script will last as long as the column is populated with values
//once this is done or aborted, the column/script will be re-initialized from scratch next 
//time it's busy for a period of time
var folderDates = {};
//caution: I'm unsure about what happens if columns are populated for two different
//folders/tabs at the same time, not sure if both folders/tabs share the same script
//context, which could unwantedly mix data in the caching variable.
//but: for folder dates this could actually be a welcome side-effect if mixing occurs.
function myColumnFunction(ColumnData){
	//..
	if (colName == 'Parent\'s Modified Date') {
			parentPath = DOpus.FSUtil.NewPath(ColumnData.item);
			parentPath.Parent();
			if (!folderDates[parentPath]) {
				parentItem = DOpus.FSUtil.GetItem(parentPath);
				modifiedDate = parentItem.modify_utc;	
				folderDates[parentPath] = modifiedDate;
			} else {
				modifiedDate = folderDates[parentPath];
			}
			ColumnData.value = modifiedDate;
	}
}
2 Likes