# What happend to @profview
**URL:** https://discourse.julialang.org/t/what-happend-to-profview/79379
**Category:** VS Code
**Tags:** question
**Created:** [April 12, 2022, 10:56am UTC](https://discourse.julialang.org/t/what-happend-to-profview/79379 "2022-04-12T10:56:21Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@deltaeecs](https://discourse.julialang.org/u/deltaeecs)
#### Post date: [April 12, 2022, 10:56am UTC](https://discourse.julialang.org/t/what-happend-to-profview/79379/1 "2022-04-12T10:56:21Z")
I used to use `@profview` (defiend in VSCodeServer) in vscode to analyze the cpu time of functions, which provide sth like this
The time costs are very clear.
But now I get different result like the following using the same macro `@profview`
where has no information about time.
The question is that how could I do profile like the old way? Appreciate if anyone could help~
---
### Author:  [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)
#### Post date: [April 12, 2022, 10:59am UTC](https://discourse.julialang.org/t/what-happend-to-profview/79379/2 "2022-04-12T10:59:57Z")
You can’t, at least not easily.
In my experience the times reported by `@profview` were wildly inaccurate and mostly useless; in general, they are proportional to the sample count also shown in the new UI, so there shouldn’t be less info here (just less pretending to give you accurate timings).
---
### Author:  [@deltaeecs](https://discourse.julialang.org/u/deltaeecs)
#### Post date: [April 12, 2022, 11:02am UTC](https://discourse.julialang.org/t/what-happend-to-profview/79379/3 "2022-04-12T11:02:05Z")
Thanks, it seems I should get used to the new one.
---
### Author:  [@gdalle](https://discourse.julialang.org/u/gdalle)
#### Post date: [April 12, 2022, 11:24am UTC](https://discourse.julialang.org/t/what-happend-to-profview/79379/4 "2022-04-12T11:24:14Z")
If you really want the table though you can always [profile manually](https://docs.julialang.org/en/v1/manual/profile/)
---
### Author:  [@jeffreyesun](https://discourse.julialang.org/u/jeffreyesun)
#### Post date: [September 7, 2022, 9:35pm UTC](https://discourse.julialang.org/t/what-happend-to-profview/79379/5 "2022-09-07T21:35:05Z")
I strongly prefer the old way. Why would you just remove a feature? It would also display the self and total times above each function. I know it wasn’t super accurate but it was extremely useful to me.
---
### Author:  [@rmsmsgood](https://discourse.julialang.org/u/rmsmsgood)
#### Post date: [September 11, 2022, 3:50pm UTC](https://discourse.julialang.org/t/what-happend-to-profview/79379/6 "2022-09-11T15:50:34Z")
Not only you. The old way is a kind of ‘matlab’ style(what i hate…), but very easy to see although as [pfitzseb](https://discourse.julialang.org/u/pfitzseb) said it’s inaccurate. I guess the inaccuracy is most big problem, and we should lean that ‘flame graph’ or anything…
---
### Author:  [@jeffreyesun](https://discourse.julialang.org/u/jeffreyesun)
#### Post date: [September 12, 2022, 7:17pm UTC](https://discourse.julialang.org/t/what-happend-to-profview/79379/7 "2022-09-12T19:17:44Z")
I did a little research and here’s what I found. The “old way” was just generating a .cpuprofile file and opening it with vscode’s built-in .cpuprofile viewer, [vscode-js-profile-visualizer](https://github.com/microsoft/vscode-js-profile-visualizer), originally designed for js profiling. This is still possible to do manually by using [ChromeProfileFormat.jl](https://github.com/julia-vscode/ChromeProfileFormat.jl) to generate a .cpuprofile file.
The “new way” is to use a Julia-specific package to display profile results: [ProfileCanvas.jl](https://github.com/pfitzseb/ProfileCanvas.jl). It’s probably a good idea in the long run to stop relying on vscode-js-profile-visualizer, and the new package also gives us control over how profile results are displayed. Unfortunately ProfileCanvas.jl is not being actively developed, so we’re stuck with the current format until somebody decides to take it on.
---
### Author:  [@gdalle](https://discourse.julialang.org/u/gdalle)
#### Post date: [September 13, 2022, 10:23pm UTC](https://discourse.julialang.org/t/what-happend-to-profview/79379/8 "2022-09-13T22:23:37Z")
@pfitzseb might have something to say about ProfileCanvas not being “actively developed” 😉 I seem to recall quite a bit of activity a few months back
---
### Author:  [@jeffreyesun](https://discourse.julialang.org/u/jeffreyesun)
#### Post date: [September 14, 2022, 6:04pm UTC](https://discourse.julialang.org/t/what-happend-to-profview/79379/9 "2022-09-14T18:04:29Z")
You’re right, sorry. @pfitzeb has indeed been doing great work on this package, indeed he’s carried it solo up till now. It’s a good package to have, and it looks great! But he is after all just one person who by his own admission doesn’t have time to work on this feature. There is an [issue](https://github.com/pfitzseb/ProfileCanvas.jl/issues/3) open for it, though, and I think it would great for new contributors to help share the load. I’m currently trying to finish my degree so time is at a bit of a premium, but I’ll lend a hand if I can find the time.
I seem to recall there being some mechanism for tagging issues as good entry points for new contributors. Would that be appropriate/possible in this case?
---
### Author:  [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)
#### Post date: [September 15, 2022, 9:38am UTC](https://discourse.julialang.org/t/what-happend-to-profview/79379/10 "2022-09-15T09:38:37Z")
As always, things like these are a matter of prioritization – we haven’t had many people telling us they’re missing the old UI, for example (roughly four, including this thread, if I remember correctly). Also note that the switch to our own UI _did_ fix a actual issues with the previous solution, I didn’t just decide to implement that for fun 🙂