Visitar URL original
MemoryTarget improvement. · Issue #6022 · NLog/NLog · GitHub
Skip to content

MemoryTarget improvement. #6022

Closed
Closed

Description

@Orace

I noticed that the current MemoryTarget implementation has a few caveats:

  • Changes to the MaxLogsCount property doesn't trim the list.
  • If MaxLogCount is positive (n), an insertion cost is O(n) (because of a call to RemoveAt(0))
  • Enumeration of logs block the writers (!)

It appears that I have a resizable circular buffer implementation that can solve those issues. It's just missing some methods from IList (insert, removeAt) but can serve as a drop in replacement of ThreadSafeList.

Activity

  1. welcome commented on Oct 8, 2025

    @welcome

    Hi! Thanks for opening your first issue here! Please make sure to follow the issue template - so we could help you better!

  2. snakefoot commented on Oct 9, 2025

    @snakefoot
    Contributor

    Yes NLog v6 should probably have changed the interface from IList to something else like ICollection / IReadOnlyList

    I would prefer something simple, that maybe rely on existing .NET building blocks. If you have something that is just as simple as ThreadSafeList then pull-request are wellcome (Along with many unit-tests if not relying on standard .NET collection).

  3. Orace commented on Oct 9, 2025

    @Orace
    ContributorAuthor

    Yes NLog v6 should probably have changed the interface from IList to something else like ICollection / IReadOnlyList

    I'm pretty agree with that 🙄

    Alas the implementation is not so simple (and not yet complete).

    I run some benchmarks, there is roughly 30% of improvement when writing 1_000_000 messages with MaxCount = 1000:

    Image

    I'm not sure it's worth it.

  4. snakefoot commented on Oct 9, 2025

    @snakefoot
    Contributor

    @Orace I guess it is possible to replace with a ConcurrentQueue that also supports reverse enumeration. Would it be something that would be useful for you? (Replaces bad performance on trim with bad performance on random indexing).

  5. Orace commented on Oct 9, 2025

    @Orace
    ContributorAuthor

    Thanks for your replies.
    In my case, at the end of the day, performance isn’t a real issue. I only need to keep the last 50 log lines for crash reports. I just noticed the current implementation could be improved and wanted to share the idea. (Since I worked on the circular buffer with bulk copy a few days ago).

    As you said, exposing a mutable list is not necessary and the API should evolve to only allow snapshots (full or partial), but maybe that needs to be a separate issue.

  6. snakefoot commented on Oct 9, 2025

    @snakefoot
    Contributor

    Created #6023 for your observation:

    • Changes to the MaxLogsCount property doesn't trim the list.

    Also think the memmove from RemoveAt(0) only hurts when having more than 1000 items in the List.

  7. snakefoot commented on Oct 18, 2025

    @snakefoot
    Contributor

    Closing issue as resolved due to inactivity.

  8. added this to the 6.0.6 milestone on Oct 24, 2025
  9. snakefoot commented on Sep 16, 2026

    @snakefoot
    Contributor

    Created #6283 that allows Logs-enumeration without blocking application logging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions