Snapshot directory + Help search
-
- Posts: 11
- Joined: Sat Sep 17, 2005 8:29 am
Snapshot directory + Help search
I would like to specify the directory the snapshots are saved to initially. My home directory gets messed up
While trying to change that directory I missed a search function in the application help, too.
While trying to change that directory I missed a search function in the application help, too.
-
- Posts: 1626
- Joined: Tue Aug 10, 2004 7:52 pm
-
- Posts: 1626
- Joined: Tue Aug 10, 2004 7:52 pm
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
-
- Posts: 46
- Joined: Mon Jan 24, 2005 3:01 pm
I think I already posted this somewhere else, but maybe it got lost: It would be nice to have the ability to save snapshots in the profiled application's current working directory by default. This can't, unfortunately, be configured through the run config defaults currently, because there is no macro available to address the cwd, neither in IDEA nor in YJP.
I'm also not entirely sure if the default configuration is truly inherited (I think it's not), or if it's copied in the moment the run config is created, so this doesn't help when there's already a number of configs present.
The home directory is also a bad default for another reason: When using server-side profiles (Windows), it can happen that snapshots of several tens of megabytes have to be synchronized with the server during logon/logoff. Kinda annoying
Apart from a "$CWD$" macro that is substituted with the current working directory, it would also be great to have a global setting (environment variable) to switch between saving snapshots in the home dir (or a subfolder) and the current directory.
Cheers,
Sascha
I'm also not entirely sure if the default configuration is truly inherited (I think it's not), or if it's copied in the moment the run config is created, so this doesn't help when there's already a number of configs present.
The home directory is also a bad default for another reason: When using server-side profiles (Windows), it can happen that snapshots of several tens of megabytes have to be synchronized with the server during logon/logoff. Kinda annoying
Apart from a "$CWD$" macro that is substituted with the current working directory, it would also be great to have a global setting (environment variable) to switch between saving snapshots in the home dir (or a subfolder) and the current directory.
Cheers,
Sascha
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
Thank you for the suggestions.
I've added a request to rework the issue to our issue tracker. Unfortunately, as we're just several days away from the release, this goes to the next version.
By the way, I think that the root of the problem is not a wrong default location of the snapshot, but the entire paradigm of snapshot files when each snapshot is stored permanently, until it is explicitly removed.
I think in many cases this would be more useful to use another paradigm: I connect to profiled application, I get results, analyse them, and, in case _I need it_, optionally store them for future reference.
That's how it works now for telemetry. You watch it and then forget it, having an option to save it to file.
The question is how to fit this into the profiler's architecture. Snapshots as files, technically, are fine, especially memory snapshots because of possibly very huge size. But from the user's point of view, the things may be different. Probably, if snapshot is captured from the profiler UI on a local machine, it's file should be marked in a "delete on exit"-like manner, which, if not explicitly "saved", will be removed after UI is closed? Or such non-saved snapshots should "expire" after given time?
What do you think?
Best regards,
Anton
I've added a request to rework the issue to our issue tracker. Unfortunately, as we're just several days away from the release, this goes to the next version.
By the way, I think that the root of the problem is not a wrong default location of the snapshot, but the entire paradigm of snapshot files when each snapshot is stored permanently, until it is explicitly removed.
I think in many cases this would be more useful to use another paradigm: I connect to profiled application, I get results, analyse them, and, in case _I need it_, optionally store them for future reference.
That's how it works now for telemetry. You watch it and then forget it, having an option to save it to file.
The question is how to fit this into the profiler's architecture. Snapshots as files, technically, are fine, especially memory snapshots because of possibly very huge size. But from the user's point of view, the things may be different. Probably, if snapshot is captured from the profiler UI on a local machine, it's file should be marked in a "delete on exit"-like manner, which, if not explicitly "saved", will be removed after UI is closed? Or such non-saved snapshots should "expire" after given time?
What do you think?
Best regards,
Anton
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
P.S.:
Default run configuration settings in IDEA are not inherited, but only copied when a new configuration is created. That's why it'd better to call the button in IDEA "Edit Template..." instead of "Edit Defaults..."I'm also not entirely sure if the default configuration is truly inherited (I think it's not), or if it's copied in the moment the run config is created, so this doesn't help when there's already a number of configs present
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
-
- Posts: 46
- Joined: Mon Jan 24, 2005 3:01 pm
Thanks. BTW I found a way to save snapshots to the working directory by entering "." in the snapshot directory, which also works with the default configuration (only for new run configs of course). No need for a macro or some other magic.I've added a request to rework the issue to our issue tracker. Unfortunately, as we're just several days away from the release, this goes to the next version.
Agreed, but of course this only applies to snapshots taken from the profiler UI.I think in many cases this would be more useful to use another paradigm: I connect to profiled application, I get results, analyse them, and, in case _I need it_, optionally store them for future reference.
I think the delete-on-exit approach is the best, as "expiring" a file seems quite unintuitive and possibly dangerous if the file just vanishes at a certain time. The problem I see is that the necessary prompt to save such temporary snapshots might be a bit confusing, especially if the list of snapshots is long.
Sascha