Member Avatar for stromgren

Dear Community Members!

I have written a program in plain C to carry out some mathematical calculations. Now I am trying to identify bottlenecks using a profiler (IDE: Open Watcom 1.8). I find that a very large portion (60-79%) of the running time is used by ntdll.dll. The core program and the few called dlls consume just a smaller portion. The profiler does not show anything inside ntdll.

As I am not a programmer (just an olap developer doing some programming on my own) I do not fully understand what this means. Google has told me it is some very basic windows dll. But why does it take so much time? First I thought it is becaue I printed some information on the screen for testing purposes but commenting out the printf-s and leaving just the calculations has not changed the situation.

Is there a possibility to improve the performance of my program somehow? Or is it normal? What does ntdll.dll do?

Thanks, S.

  • 2 Contributors
  • 2 Replies
  • 418 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by stromgren

Dani AI

Generated

As hinted and later verified, a large percentage of profile time tagged to ntdll.dll usually means the program is spending most of its runtime in kernel-mode work invoked from user code (syscalls, paging, waits), not that ntdll itself contains slow algorithmic code. The Process Explorer observation of many page faults points to hard page faults (disk I/O) as the real cost: when a thread faults waiting for pages, sampling profilers commonly attribute that stalled time to the system transition point (ntdll/kernal boundary).

Short, practical diagnostics that give clarity: confirm whether faults are hard or soft by watching Process Explorer’s Hard Faults/sec or Perfmon counters (Memory\Pages/sec, Process\Page Faults/sec, Working Set, Private Bytes). Use VMMap or Process Explorer -> Properties -> VM map to see which module or allocation type holds the biggest committed/resident footprint. Reproduce with a minimal model and run the solver standalone so memory growth and fault rate can be correlated directly to lpsolve’s activity.

Mitigations that tend to work: reduce peak memory usage in the solver (smaller models, sparser representations, streaming/out‑of‑core algorithms), run on a machine with more physical RAM or a 64‑bit build to avoid address-space limits, or switch to a solver/version with friendlier memory behavior. As a targeted tactic, pre‑touching newly allocated large buffers forces commitment while latency is acceptable; pinning pages (VirtualLock) or forcing working-set sizes requires privileges and can harm system stability, so treat those as last resorts. For precise attribution of which call inside the solver triggers the kernel work, capture an ETW trace (Windows Performance Recorder/Analyzer) with symbols — that will show the stack that actually caused the fault rather than just the ntdll frame.

In short: ntdll is a symptom location in profiles; root causes are usually the third‑party allocator/algorithm that causes high hard‑fault rates. Reducing memory pressure, using appropriate builds/tools, or running the solver where more RAM is available are the reliable fixes.

Recommended Answers

All 2 Replies

Member Avatar for dwks

This page says that ntdll.dll is "a Native API file of Microsoft operating systems and it contains NT kernel functions". Kind of vague, but perhaps if the code is doing any system calls (accessing files, perhaps), that may account for it. Or perhaps if your program uses a lot of memory, some virtual memory software may be kicking in to move your data from disk to RAM periodically.

Does your hard disk get much usage while the program is running?

Member Avatar for stromgren

This page says that ntdll.dll is "a Native API file of Microsoft operating systems and it contains NT kernel functions". Kind of vague, but perhaps if the code is doing any system calls (accessing files, perhaps), that may account for it. Or perhaps if your program uses a lot of memory, some virtual memory software may be kicking in to move your data from disk to RAM periodically.

Does your hard disk get much usage while the program is running?

Hello DWKS! Thank You for your answer.

You have the point. I watched Process Explorer during a long series of repeated running of my program. I saw a lot of page faults. So that slowed down my program.
It turned out that the lpsolve 5.5 's dll, more exactly the solution of the linear programming model produced the large number of page faults. Putting that line into comment dropped the % portion of the ntdll in the running time. So my original problem is solved, but I am not so happy having found that an outer party dll causes everything. I do not see yet how it can be influenced.

Anyway, you showed the right way, thanks again.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.