Improve performance-sensitive scripting by reducing mandatory singleton method usage

Feature Requests Engine Features
, ,
1

As a Roblox developer, it is currently too hard to write clean and efficient performance-sensitive code when commonly used functionality is only exposed through singleton service methods.

Many core APIs require calling methods on singleton services even when the operation itself does not depend on mutable service state. In high-frequency execution contexts (such as per-frame or per-input updates), this leads to:

  • repeated singleton access in hot paths
  • limited ability to cache callable logic
  • reduced code clarity when object state is not conceptually involved

This makes it harder to write performant systems while keeping code easy to reason about.

If this issue is addressed, it would improve my development experience because it would allow me to structure hot-path logic more clearly and efficiently while maintaining readable, beginner-friendly code.

This would:

  • reduce unnecessary overhead in frequently executed loops
  • make intent clearer when an API does not rely on object state
  • improve maintainability in systems like camera controllers, input handling, and per-frame logic
  • support better mental models around when methods vs functions are appropriate

Use Cases

  • Camera systems querying input every frame
  • Input processing inside PreRender (mouse delta and such)
  • Performance-sensitive gameplay or animation systems (Tween creation)
  • Large projects where hot-path optimization is important but clarity must be preserved

Additional Context (Non-prescriptive)

Some APIs could conceptually support function-style access in addition to existing methods. This would allow developers to cache callable logic once and reuse it efficiently without passing service singleton as an argument, without removing or breaking current APIs.

This is not a request to remove singleton services, but to provide more flexibility in how frequently used functionality can be accessed.

Why this matters

This request is focused on improving developer ergonomics, clarity, and scalability in performance-sensitive code, rather than large architectural changes. Even small reductions in overhead and ambiguity can have meaningful impact at scale.

4 Likes
2

I am unsure what this feature request is asking for in specific. It feels like it is focused on the solution rather than the problem.

Do you have examples of code that you are trying to replace?

3 Likes
3

I can clarify with concrete examples.

The issue I’m running into is that many APIs which are conceptually stateless are only exposed as methods on singleton services, which forces service access in hot paths even when no service state is involved.

Example 1: UserInputService in per-frame logic

local UIS = game:GetService("UserInputService")

RunService.PreRender:Connect(function()
    local delta = UIS:GetMouseDelta()
    -- camera math
end)

In systems like camera controllers, this runs every frame.
The functionality itself (getting mouse delta) does not depend on mutable UserInputService state, yet it must be accessed through the singleton each time.

This makes it harder to:

  • cache callable logic cleanly
  • reason about what is actually stateful vs functional
  • write tight hot-path code without repeatedly touching global services

Example 2: Tween creation

local TweenService = game:GetService("TweenService")

local tween = TweenService:Create(part, info, goal)

Create does not conceptually depend on TweenService instance state, but it can’t be cached or referenced as a standalone callable without also passing the singleton.

In larger systems where tweens are created frequently, this adds noise and reduces clarity around intent.

Example 3: General pattern

Across multiple services, the pattern is:

  • functionality that behaves like a pure function
  • exposed only as a method on a global singleton

This encourages designs where everything looks stateful, even when it isn’t, which hurts readability and optimization in performance-sensitive systems.

What I’m trying to improve

I’m not asking to remove services or redesign APIs, but to reduce friction when writing hot-path logic by allowing commonly used, stateless operations to be accessed without repeatedly going through a singleton service.

The problem I’m highlighting is ergonomics and clarity in performance-sensitive code, not just micro-optimization.

2 Likes