[BUG-232867] llGetNotecardLineFast - Fast notecard reads for in-cache assets

[sl-service-account]

How would you like the feature to work?

Add a new llGetNotecardLineFast function with the same signature as llGetNotecardLine. This new *Fast version will not have a delay if the notecard being requested is already in the region asset cache.

Why is this feature important to you? How would it benefit the community?

llGetNotecardLine is infamously slow, with a built-in delay of 0.1s per line. This adversely impacts all sorts of scripts in Second Life, notably when scripts need to load user-customizable configuration (Furniture, etc.)

By introducing a new *Fast permutation of the function (Similar in style to llSetLinkPrimitiveParamsFast, etc.) we can allow any behavior that depends on the built-in delay to function as expected while giving creators the ability to opt-in to a faster method.

The new function would feature a delay (0.1s or similar) if the notecard being requested needs to be downloaded into the current region's asset cache. This is necessary as notecards can be referenced by asset ID, and presents a more transparent and fair representation of lookup cost.

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-232867 | | Summary | llGetNotecardLineFast - Fast notecard reads for in-cache assets | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Signal Linden (signal.linden) | | Created at | 2022-11-04T14:52:30Z | | Updated at | 2022-11-09T19:05:48Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2022-11-04T11:24:24.627-0500', 'How would you like the feature to work?': 'Add a new llGetNotecardLineFast function with the same signature as llGetNotecardLine. This new *Fast version will not have a delay if the notecard being requested is already in the region asset cache.', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': "llGetNotecardLine is infamously slow, with a built-in delay of 0.1s per line. This adversely impacts all sorts of scripts in Second Life, notable when scripts need to load user-customizable configuration (Furniture, etc.)\r\n\r\nBy introducing a new *Fast permutation of the function (Similar in style to llSetLinkPrimitiveParamsFast, etc.) we can allow any behavior that depends on the built-in delay to function as expected while giving creators the ability to opt-in to a faster method.\r\n\r\nThe new function would feature a delay (0.1s or similar) if the notecard being requested needs to be downloaded into the current region's asset cache. This is necessary as notecards can be referenced by asset ID, and presents a more transparent and fair representation of lookup cost.", } ```

[sl-service-account]

Signal Linden commented at 2022-11-04T15:37:36Z

For consideration: make llGetNotecardLineFast synchronous and return the requested line.

[sl-service-account]

Lucia Nightfire commented at 2022-11-04T16:24:25Z

Since notecard data is already downloaded and cached by the server when calling llGetNotecardLine() or llGetNumberOfNotecardLines(), I don't see why we can't have synchronous notecard line read capability.

The function could simply return a null string if notecard data is not yet cached.

[sl-service-account]

JIRAUSER341305 commented at 2022-11-05T08:08:09Z, updated at 2022-11-05T13:20:24Z

I DEEPLY vote for "make llGetNotecardLineFast synchronous and return the requested line."

Just needs to return a new magic value that indicates, 'notecard is not cached".  When you get that, you do a regular llGetNotecardLine(), and can start slamming down the llGetNotecardLineFast()s again.  It doesn't remove the need to do the whole event-driven thing, but, it should get the speed benefits.

And this is a waaaaay better idea than that silly loading notecards into the linkset data nonsense…  It's already in the sims cache, why make it occupy twice (more, realistically) as much memory, which simultaneously effectively robbing us of the newly added feature (which most people will probably solve by adding an extra storage script (or two) to hold the linkset data until they're done with the notecard, so they can load it all right back in again.)