Hi Aaron,
You're correct that there were significant changes to LAGMATRIX in the R2022a release. In fact, the function was substantially rewritten. Part of this was to bring old code up to current standards and patterns used elsewhere in the toolbox for things like input parsing and error checking. More substantially, the function was updated to accommodate new input data types, like tables and timetables, and new features, like the ability to specify pre-sample and post-sample data, and the shape of the output. These changes are documented in the Release Notes section of the LAGMATRIX reference page.
That said, you probably aren't interested in any of these new features, at least in the application you describe. If you were relying on R2021a functionality, you were inputting a numerical matrix and returning a numerical matrix. In the new version of LAGMATRIX, much of the new code for handling tabular data will be bypassed in that scenario. However, some of the new, and different, error checking is added to the code path in any input scenario, and while the difference in execution time is insignificant in any single call to LAGMATRIX (our most typical user scenario), it adds up over the 194703 calls you describe.
You indicate that you're evaluating an objective function in some sort of optimization. It's typical for solvers to evaluate the objective function many times in a single iteration, and if the optimization is slow to converge the number of calls to the objective can reach the levels you describe. For this reason, objective functions should be as lean as possible. Assembling toolbox functions, though they're optimized for their intended purpose, may result in the unsatisfactory slow-downs you're experiencing. Fortunately, our toolbox functions are all open-source ("toolbox" suggests building your own applications), so the core code for lagging a matrix is available to you without all of the parsing, error-checking, and other features that are irrelevant to your use case. In these circumstances, our suggestion is always to use only the core code necessary (lagging a time series is pretty simple). If you do this, you'll see a performance improvement over even the R2021a release, and one that will not be affected by any future updates to the toolbox.
