Community Spring Cleaning week is here! Join your fellow Maveryx in digging through your old posts and marking comments on them as solved. Learn more here!
The Product Idea boards have gotten an update to better integrate them within our Product team's idea cycle! However this update does have a few unique behaviors, if you have any questions about them check out our FAQ.

Alteryx Designer Desktop Ideas

Share your Designer Desktop product ideas - we're listening!
Submitting an Idea?

Be sure to review our Idea Submission Guidelines for more information!

Submission Guidelines

The Default Value For a 1073741823 V_String is ridiculous and never useful. Change it!

Who needs a 1073741823 sized string anyways?  No one, or close enough to no one.  But, if you are creating some fancy new properties in the formula tool and just cranking along and then you see that your **bleep** data stream is 9G for nine rows of data you find yourself wondering what the hell is going on.  And then, you walk your way way down the workflow for a while finding slots where the default 1073741823 value got set, changing them to non-insane sized strings, and the your data flow is more like 64kb and your workflow runs in 3 seconds instead of 30 seconds.  

 

Please set the default value for formula tools to a non-insane value that won't be changed by default by 99.99999% of use cases.  Thank you.

 

 

14 Comments
ChrisK
Alteryx
Alteryx

I'm puzzled by your observation that changing the limit on a variable width string changes the performance of a workflow. If you were talking about fixed sized strings, I'd understand. Fixed size strings (String and WString types) always use the size you say they take. Variable size strings (V_String and V_WString) use a few bytes to give the size, then use just the number of bytes the string actually needs. The limit is there only as a backstop; so you get a warning if the workflow does something crazy. Yet you observe that changing the upper limit changes the performance of the workflow. Can you show us an example of this? I wonder if there is something more going on here.

Balders
11 - Bolide

.

RachelW
Alteryx Alumni (Retired)
Status changed to: Duplicate
 
jsh562
7 - Meteor

Being able to set default values per workflow and/or per data stream would be much more useful than just changing the default.

Atabarezz
13 - Pulsar

Duplicate of which previous idea? Can you please share the link?

KylieF
Alteryx Community Team
Alteryx Community Team
Status changed to: Comments Requested

Thank you all for contributing to this idea and posting on the Alteryx Community!

 

Your idea is something we may be interested in pursuing, but we need a little more detail to conceptualization the impact fully. Would you be able to provide us an example of how the V_String value effects the performance of your workflow?

 

joshuaburkhow
ACE Emeritus
ACE Emeritus

I have never noticed it performance wise. Is it crazy huge yeah but it's exactly right what @ChrisK said "Fixed size strings (String and WString types) always use the size you say they take. Variable size strings (V_String and V_WString) use a few bytes to give the size, then use just the number of bytes the string actually needs."

 

If there is a performance issue than that needs to go to support. 

brianscott
11 - Bolide

@ChrisK -

@KylieF 

 

I knew I'd seen this, but then couldn't replicate it.  But then I did.  And then I saw a star on this thread this morning so I thought I'd update. 

 

The problem comes if you convert a V_String to a String (i.e., use a select tool change up), and then *forget* to change your size to a realistic value.  In my instance, I've still got a bunch of 32 bit oracle instances I need to write to, and they bork when I try to pass them V_String values (I only get 1 character written to the database).  So I will frequently need to tweak from V_String to String, but if you do it midstream and don't reset your sizes, you get the performance hit I referred to.  Probably an edge case, but other people may have problems writing to a database with V_String that I don't know about.   

 

Weird.  Cannot attach a workflow, but see the picture.  Easy to replicate. 

 

brian

VStringToSTringSnapshot.png

 

ChrisK
Alteryx
Alteryx
I understand! So it's more that the select tool just slides a ridiculous value to the size of a fixed size string. I wonder if UX might have a suggestion for how to flag it. What do you think if you were to change from V_String to String, and if the size is over some limit (16 K for example), the field just goes empty with a red border and you are required to give a value yourself. (You can give whatever you like, but then it's on you.)
bkramer66_dup_418
6 - Meteoroid

I didn't fully appreciate the potential scale of this until just yesterday when I saved several output files in the .sav format (to do some GLM in SPSS) and didn't pay attention to two string fields in each that had defaulted to V_WString with the crazy character length. I was exporting about 500 records with about 15 fields, mostly numeric, in each file, constituting very small datesets. However, when I looked at the size of the files, I was astounded - 4.5 Mb when they should have been around 100 Kb. I immediately thought of this thread, went back and changed the size to 8 for both fields and wa-la...only around 125 Kb.

 

So yes, this happens, and while outputting to .sav is probably somewhat rare compared to other formats (and hence, I am not sure to what extent this behavior is replicable in other formats), I can honestly now see the potential implications, especially for "more normal-sized" outputs where file sizes are much larger than my puny little datasets on which I was running some tests.

 

Changing the default size to something "more reasonable" would preclude the inadvertent ballooning of files.